Never heard of a project like that. Not only would such a FPGA have include C128 but also C64 and Z80/CPm.
FCUG celebrating 33 years,
Fresno Commodore User Group
July 18-19 Commodore Vegas Expo v11 -
Complete FPGA implementation - no.
A semi-discreet re-implementation ... yes ... mine.
I am *actively* working on a re-implementation of the 128, but it's not totally based on a FPGA. I'm using semi-original components (for example - MPU is the WDC 65c02), the Z80 is a *real* Z80 - albeit the 20MHz CMOS version (just not running at 20Mhz though).
Where it does differ though is that for the CMD specific ICs (which is *most* of them ... unfortunately) is that I'm trying to re-implement them in Verilog with the intent of targeting either a FPGA or a CPLD. My Verilog at this stage is pretty awful so this has been a major learning curve.
As of this minute, current schematic has a XC95288 CPLD at its heart but that may change. As I've learnt - CPLDs are great for absorbing huge amounts of discreet TTL logic but there aren't so good when you need to start creating lots of registers and so forth internally - you burn up the resources at a *horrific* rate. At that point - a FPGA really is the way to go (there really is a *lot* to be said for an FPGA with small bits of memory scattered inside it).
Problems with this though is that you simply won't get a 5v FPGA these days and even getting 5v *tolerant* FPGAs is getting really, really hard. A this stage, you need to start using level converters ... and ... yeah ... there goes a lot of your simplicity simply because you're talking to 5v devices. The way that I *may* get around this is to either go that route or using the CPLD as a level translator while keeping the majority of discreet logic cr*p out of a FPGA. FPGAs with 3.3v tolerant I/O are *lot* more common and the CPLDs I've got will handling both 5v and 3.3v I/O without any issue.
Significant changes to the original 128 are as follows....
1. MMU now supports *4* banks and *all* of the MMU, PLA and some of the associated glue logic is all wrapped up in the core - that part I'm actively working on at the moment. The 4 banks part has been a *personal* bugbear of mine with the 128 for as long as I can remember. At some stage, I'll make a video on how I scre .... err ... tortured .. err ... 'modified' the 128 to give it an additional 128Kb of memory taking it to 256 internally (yes ... it has to do with allowing me to have a very primitive compiler, assembler and linker all in core back in the early/mid 80s). You have to remember, I added memory to my 128 *before* the REUs were widely available here in AU (they were as rare as rocking horse sh*t - the only thing rarer was the mythical 1581 - to this day, I have *never* seen one in real life).
2. REU is now in-core (I started this one *first* and it is *sort of* done. Having learnt a lot more about Verilog than I knew about it when I started on the REU, I've made some nasty mistakes which I'll need to go back and fix. Actually 'fix' is the wrong word ... throw out and rewrite from scratch would probably be far more appropriate ... it's truly *awful* - the benefit of hindsight).
3. Z80 is planned to run in *parallel* to the 6502. It is fully connected to the CPLD, and so the CPLD at the moment is intended to act as a traffic cop so memory isn't shared so much - with the following additional twist ... I'm using using some dual port SRAM to connect the two. The upside of this is that you no longer need to run both at the same clock rate. At this stage, the Z80 *still* sets up the various vectors and so forth before flipping the 6502 reset register which controls the 65xx reset line (!RST) which then flows out to the various 65xx ICs.
Related problems and twists to this (apart from Verilog).
The 'custom' chips of which most of them generally are, are a *huge* pain in the arse. On the 128 you've got stuff hanging off everywhere because it was convenient to do so (need to add an extra control line for the keyboard - let's hang it off wherever we can find a free pin - VIC/CPU/where ever).
Ones which I really don't want to think about at this stage are the SID (right now - *NO* sound or if I do it - supply your own SID). Maybe SwinSID would be an alternative there.
The problem is that for anything that uses the 1351 mouse, or the POTS, you need a SID so I'm kinda hooped there.
The VIC... which is a piece of work in itself ....
... oh... and that other perennial 'favourite' which even 30 years later on is *still* causing misery to anyone who is unlucky enough to cross it's path is the 8563 VDC. I truly *HATE* that chip ...
I started with that one with the first prototype board, a basic 6502 and a bit of memory, and that nearly killed/drove me loony then. I've since been informed that had I started with the 'fixed' 8568 that I would have had a lot less pain and misery ... again .. the joys of hindsight .... <sigh>
Where this part time insanity projects sits at the moment ... it's a mixture of some FR4 manufactured boards with bits and pies hacked, cut, sawed and soldered onto them, some prototype boards with an even bigger mess of wires and cr*p hanging everywhere everywhere - and most are interconnected with strips of 50 and 64pin ribbon cable (2.54mm headers). It really is a science experiment gone seriously wrong.
Current project state ...
I have had to remove the smoke alarm from my office/testlab and I now have a CO2 fire extinguisher near my bench ... so that will give you some idea as to it's current stability ..
* Current schematics ... all done in Eagle (pro) + plus a mixture of the above printouts with pen scribbled across them for things I've found to cause the magic smoke to get out of various things. On the CAD side (with Eagle) I've been breaking things up into logical modules, various sheets and so forth in a vain effort to try to make it all a lot more readable and understandable - shame that bugger all of it works even remotely like anything like correctly ...
* Current Verilog for the CPLD/FPGA stuff is all done in the Xilinx ISE 14.7.
* Current spouse amusement level ... getting pretty low - "Burn the house down, and I'll kill you".
Only thing I'm even semi-wiling to release to the public because the rest is so *bad* or such an embarrassment is the Eagle libraries. I've spent a fair bit of time making sure those are actually looking pretty good now.
It's a shame the rest is complete and utter cr ... errr ... "not ready for public consumption".... lest the rest of the electrical engineering and hacker community would land on my doorstop and take away both my oscilloscope and soldering iron on on the basis of reducing the amount of crimes against good electrical design practises.
This is a part time and on the side project otherwise my missus would have almost certainly killed me by now.
> A semi-discreet re-implementation ... yes ... mine.
> I am *actively* working on a re-implementation of the 128, but it's not totally based on a FPGA. I'm using semi-original components (for example - MPU is the WDC 65c02), the
> Z80 is a *real* Z80 - albeit the 20MHz CMOS version (just not running at 20Mhz though).
Ah, I don't really care if it;s called an implementation or a re-implement ation... as long as it works. :)
> ...'modified' the 128 to give it an additional 128Kb of memory taking it to 256 internally...
Hmm, just like the proposed Commodore 256 that Dave Haynie worked on?
> The problem is that for anything that uses the 1351 mouse, or the POTS, you need a SID so I'm kinda hooped there.
Well, a user would have to provide his/her own SID. If SwinSID ever gets input functions, then that would be an option.
> ...the only thing rarer was the mythical 1581 - to this day, I have *never* seen one in real life...
Heh, we raffle off a 1581 at CommVEx every year. :)
Raffling off those myths,
Fresno Commodore User Group
>> Hmm, just like the proposed Commodore 256 that Dave Haynie worked on?
I've never heard of that one. Was there a successor to the 128? If there was, then that sounds like it would have been an interesting beast. The 10th pound that Bil often alludes to perhaps ...
> I've never heard of that one. Was there a successor to the 128? If there was, then that sounds like it would have been an interesting beast.
Yes, Dave Haynie worked on a prototype, but it never got out of that stage, unfortunately. See
CBM was looking beyond 8-bit, banking its fortunes on the Amiga computer.
By the way, there are plans on the Net on how to convert a C128 or C128DCR into having internal 256K RAM (or even 512K RAM). See
and the newer
Though the creator of such a machine says that it has been demonstrated at a computer club meeting, Bil Herd says that it could be built far more efficiently. Bil, how do we improve it specifically?! :)
Fresno Commodore User Group
Do you have and block diagrams, circuit diagrams for the MMU? After I pieced together a bunch of documentation for it, I'm starting to be able to unlock the true power boosts it lets you wield, seems to have a few "fun" gotchas and caveats though. It is a very powerful chip just you have to hunt to get the info.
Also making a CPLD replacement for it with the 1Meg extensions you planned should be easy to do I think.
Yes, but in the *wrong* direction.
I've run in a bunch of different problems associated with some of the early design decisions that I made have wound up coming back to haunt me by biting me in the a** rather badly (if I have learnt *anything* from compatibility, it's what *not* to do).
If there is enough interest, what I'll probably do is make a video which describes all the things done, the horrible (in hindsight) decisions made and where to from here. If there is enough general interest in the project as a whole I'll probably throw it open, though at this stage, I'm wondering if it is actually worth it as some of the very things that I wanted to "fix" actually wind up making it a lot more incompatible than I had previously thought was going to be the case.
As a side note, I do have to make a shout out to Kevin Davidson who has been a invaluable source of information (ex Commodore repair here in AU and general good guy) while working on this. Kevin unfortunately lost his fight with Pancreatic Cancer last month. Amongst the many design review decisions and subtle mentoring that I have to thank him for, he not only showed me the mythical 1581 but according to his wife, he wanted me to have his 128 related stuff so I now own (amongst other things of his), a real life 1581, which I have now dubbed "Kevin".
The DTV has a few issues, some games were patchable, for example Mayhem in Monsterland has a patch, but demos forget it.
Jens is very good, has some issues still but mostly minor stuff
Mega=65 is a 65 clone and hence they are cloning the VIC III which they have just pushed passed to make a VIC IV. From the doc's I've read the VIC III was to be "officially" compatible with the VIC II, i.e. it did 8 sprites, char mode, ecbm, bitmap mode etc as per the registers. Since it did higher clock rendering and was not "locked" to the CPU clock like the VIC II it stored all register writes and then latched them at HBlank. So any effect that needs to change a register at clock X would fail. VSP, FLD, Line Crunch etc But Sprite multiplexing should be safe and open borders should also work. Sprite stretching may or may not working depending on when in HBlank it latched, start of the border or end of the screen, or end of the border. Also said latching time would cause a pile of issues for most games.
The VIC III is named Bill, anything to do with you Bil?
Are you looking for the Mega65 project?http://mega65.orghttp://mega65.net
Using the CMOS 6502 is going to give you problems. The CMOS doesn't support the illegal op codes, which are used a lot more that I though ;)
I have a 1581 in aus ;) Burst Mode 1581 is a delight to behold.
Do you have a the MMU part working yet, being able to have a drop in replacement with extra bank support would be nice.
In my musings of if we made a C128 Reloaded, what could we do. If one is happy to throw most of the compatibility out the window. The 128s block diagram hints at great things but sadly the internal copper tracks don't allow for. The 2 64K banks having their own bus. I would put a large "clutch" chip in the middle, so you can have
|8502| Z80| VIC|
| LO | HI | LO |
| HI | HI | LO |
| HI | LO | LO |
| LO | HI | HI |
| HI | HI | HI |
| HI | LO | HI |
Which allows you to put say the Z80 as the GPU/APU slave to handle and control the VIC&SID and its splits and interupts while the 8502 runs in the other RAM bank to do its logic and updates. Or you could put the Z80 into the other bank while the 8502 is paried with the VIC chip. The CPU that is not in the same bank with the VIC could run at Turbo speed. But with the modern components, high speed RAM you could also make a super turbo wich runs the CPU from the .dot clock
Sorry didn't get the email to say there was a reply.
Not tri-state to split the bus, actually split the bus and then you need something that lets you swap the lines, like a figure 8 on train tracks, you can keep the trains on the same track or cause them to both swap tracks.
So the 128,all the RAM chips have a single 16 bit bus and then you have the extra line to select Bank 0 or Bank 1.
I would have 2 16 bit buses one for each RAM "set" so they are separated. Then you use the "clutch" to pull the CPUs of the buses and switch them over and then connect again So foot down on pedal, CPUs off the buses, switch the gear, lift foot again was the metaphor I was going with.
So you have 8502 on Bank 0 and Z80 on Bank 1 or Z80 on Bank 0 and 8502 on Bank 1, it basically swaps the CPU address lines to the "bank" address lines. It can also swap the VIC.
I guess it would be a 3 24 bit muxes connected to some tri-state buffers, 1 for the 8502, 1 for the z80 and one for the VIC. It would probably need some logic to fire an IRQ on the 8502 and z80 post re-connection so you can get them both back to a known state and location to do any fix up you need to do, as it may have just lost its previous stack and code.
Ability to Halt one CPU and then switch other CPU into its mem space so you can modify things, then change back would also be needed.
Say you have the Z80 paired with the VIC in the upper bank, and the 8502 in the lower bank.
When the frame is done, the 8502 needs to update the new entity positions to the Z80 for it to sort and plex animate, move etc. Play SFX, switch song etc So you pause the Z80, allow the 8502 to see part of the Z80s RAM using the MMUs Share RAM system, write the new values into the Upper bank, drop shared RAM, resume the Z80.
Given you a system where the Z80 is the GPU+Sound driver and you have the 8502 in 2Mhz ( it doesn't share a bus with the VIC ) to do your game logic.
Ah, Sounds like you are talking about a crosspoint bus switch or bus exchanger. If I were to do something like this rather than lots of buss wires between lots of pins I think I would just connect everything to an FPGA or even some of the CPLDs would have enough guts (more about pins than intermediate logic)
With that said my gut would be that the point of diminishing returns is right around the corner given the need to get off the bus so often for the graphics processor (every low cycle and then DMA's)
How I would Really do it if implementing in silicon would be to use an FPGA and attach some fast memory to it with a memory access prioritizer/arbitrator and some FIFO to buffer the access so that the value is always available in real time independent of just exactleywhen the RAM was accessed. Fast processors could burst ahead and then get carefully held based on bus availability, meanwhile the arbitrator/buffer makes the memory look like dual or triple port with little interaction between the data consumers.
Of course then it starts to get complicated when starting to look at special situations like read-modify-write if theer are two sources of writing active at the same time.
I don't think the switching would happen that often. During VBlank mostly. You don't need to switch in and out with the VIC etc because the CPU that is paired with the VIC would share like it does now with the VIC. Say you have VIC + 8500 one Bank 1 and Z80 on Bank 0 you would have an access like this
cycles in 2Mhz
Bank 0 1
1 8500 Z80
2 VIC Z80
3 8500 Z80
4 VIC Z80
5 8500 Z80
6 VIC Z80
1 VIC Z80
2 VIC Z80
3 VIC Z80
4 VIC Z80
5 VIC Z80
6 VIC Z80
7 VIC Z80
8 VIC Z80
Then when you Z80 need to write data to Bank 0, as it in VBlank mode the VIC is in 2Mhz mode
1 Z80 -
2 Z80 -
3 Z80 -
4 Z80 -
5 Z80 -
6 Z80 -
7 Z80 -
8 Z80 -
So it just uses the normal bus sharing and clock stretching system in the 128 at the moment, just the 2 64K banks have their own bus... how one does DRAM refresh is another thing ;)
Your way, aka the PC/Amiga/Chameleon way would be the way to do it to get past the 1Mhz and the VIC barrier. Which certainly warrants investigation. As the VIC has mostly known access patterns, i.e the screen codes will be a row of 40, chars, once we know what the char is the memory is is going to access is going to be the next 8 bytes. Unless you are doing IFLI and forcing extra badline, or a bad line each line, FLD which is going to delay the badlines and VSP where you delay the DMA by N clocks.
RWM is only important on 3 addresses, D019, DC0D and DD0D, so putting in a hardware trap for those would be a possible work around. I.e snoop the opcode before and if you know it is a RWM and then the address = one of those, mimic it to the VIC/CIA chip other wise ignore, do a forced inject into the event queue.
The goal is to be flexible
So the 128 has these options at the moment
1 CPU either bank + VIC either bank at 1Mhz
1 CPU either bank at 1 Mhz
1 CPU either bank at 2 mhz
Just having the option to have
1 CPU + VIC in opposite banks at 2 Mhz
as well would be a massive boost
But if you are Dual Core expand to
1 CPU either bank + VIC either bank at 1Mhz
1 CPU + VIC in opposite banks at 2 Mhz
1 CPU either bank at 1 Mhz
1 CPU either bank at 2 mhz
2 CPUs opposite banks at 1Mhz
2 CPUs opposite banks at 2Mhz
1 CPU at 2Mhz + 1 CPU & VIC at 1mhz in opposite banks
Oh boy .... is that a *big* one.
Regarding the CMOS 6502 (i.e. WDC 65C02) vs the 8502 and illegal op-codes, you are absolutely right, but you probably don’t realise just how right you are.
When I started, I knew that was going to be an issue, but I simply had no idea as to how *big* of an issue that was going to be. You would be amazed (I certainly was) as to how often they are used.
My initial thought on the subject when I started this project that that this was only going to be a minority. It was an assumption, that in hindsight can only be “kindly” put as naive (I would rather it be called for what it is … a huge, monumental screwup of near biblical proportions). Even when it was pointed out to me by someone who was a lot more knowledgeable than I, I was ... let's say it … still skeptical to say the least.
That was, up until we built a small test rig for a real 128 to test it (a 65C02 daughter board, with a CPLD to mimic the IO ports and some other logic), and then attached a logic analyser on it), and proceeded to spend the next three days of a long weekend going through about 120 odd different C64 and C128 titles.
Yes boys and girls … we had no less than a 50% failure rate … and why … well … use of those undocumented op-codes. You may think that such behaviour was constrained to just copy protections and such like for game loads ... but no ... you'd be wrong. They are used in more things and in more places than you would think.
Even GEOS 64 (at least the version I have to test here - 1.2 I think it was) makes use of some of the undocumented op-codes. In others, they actually exploit the 65xx bugs like the broken indirect JMP.
If nothing else, it highlights just how "creative" programmers were with 6502/6510/8502 opcodes.
… and at this point, I have to step back and eat some *very* humble pie. I would love to quote Douglas Adams regarding his comment regarding the size of space in relation to how *bad* of an assumption that this was.
Regarding the MMU ... I didn't deal with that as a single atomic unit. I had better explain myself a bit better here.
In the 128 your core arbitration logic is spread across three main ICs - the PLA, the MMU and to a lesser degrees the I/O ports on the 8502 itself (they’re probably better described as levers in this context but I digress). you have additional 74 series ICs scattered around the place for additional decode but for most part, the majority of the arbitration is handled with these three main ICs (with input from the VIC as well as the external expansion port).
What I did was take all of that and group all of the logic group into the single XC95288 CPLD (hey why not … I’ve got a sh*t load of macro-cells and a whole stack of pins so it logically makes sense right). So my re-implementation of the 8722 was never a *single* IC, and in fact it was really just a part of something larger. It isn’t a “plug in replacement” for the existing single chip (i.e. the 8722 MMU).
The illegals are an issue, but RWM modify is a much bigger one.
How do you ack an VIC interrupt
INC $D019 this uses the RWM hack to do it, the real right way is
so the C range will do RMW which won't work.
The next good one is the Incorrect Index Read
This will read from DC0D and DF0D
I would go for a 65816
a.) it is a lovely processor with ALL the nice extra op-codes ( hidden behind a hidden status bit)
b,) it handles the ,x case correctly
c.) has a lot of handy output signals that make it easy to handle the RMW to RWM conversion
d.) things have been patched for it like GEOS because of the SCPU
But my 65816 cpu board is going to have a 6510 slot in it still so you can fall back when you need to ;)
It won't solve the illiagal issue, for that you are going to need a NMOS device or a soft emulated core
There are issues the length of my arm with changing the processor from NMOS to CMOS. If anyone ever says "just stick in a newer chip" ... yeah right... BS ...
Take it from me ... *doesn't* work.
There are a not insignificant number of chickens, goats and virgins to be sacrificed in the background.
Let's not mention some rather subtle timing differences.
Now ... all of that is an aside ...
As you have very correctly pointed out, to "truly" mimic a 128, you either need a *real* 8502 *or* you use a FPGA with a 65xx core that has support for the various undocumented op-codes.
Personally, I'm not so keen on having to try to use a 8502. The whole ideas was originally to try to step away from the *real* Commodore ICs so the last thing I wanted to do, was have to have a real 8502 inside it.
One of the gents I was working on this with was toying with the idea of setting up a real 8502 as a 3rd processor which you can switch to. He was working on that when his health took a dive. Personally ... I can't see that option being resurrected. It was an option that just didn't do it for me (I humoured him because ... well ... I just didn't have any better ideas at the time and was still cursing myself).
What I did have working on a test board is a Z80 and a 65C02 working in parallel, interconnected by a bit of shared memory, and both connected to the XC95288 CPLD. Just like the real 128, the Z80 in mine starts first and then does some checks before twiddling a register in the CPLD which then brings the 6502 online. Note that the Z80 actually doesn't stop ... it just goes into a tight loop in it's own set of ROM, though as it is a CMOS device, you can pretty much grab it by the throat at any point.
(Note ... separate ROMs for the Z80 and 6502, so each side can only see it's own ROM - both can see the DP SRAM but not the others ROM).
I/O is "shared" to a point but that was as far as I had got with it when it all turned pear shaped. The CPLD handles arbitration and the additional address lines (i.e. it gives you the additional 2 address lines to both sides, giving 18 bits of addressing).
Regarding the 65C816 ... err ... no.
Look, I agree that the 65C816 is *nice* in that, yes it does make a lot more things considerably nicer to deal with.
In many respects, it reminds me of the 6809.
The problem is that the way you have to address memory with it made compatibility a nightmare, so when I was first drafting it out, so I kept like for like where possible to make re-implemntation easier.
For the 128 I would ditch the upper 8 bank bits ( 6502 mode ) and stick to 64K pages with the MMU, wasn't suggesting you give it the full 24bit bus to do memory access. ( letting those 8 bank bits be the active MMU CCR register value could be fun though :D )
The '816s signals to tell you that it has a Valid Address, Valid Data or is doing a Vector Pull should make your shared design easier. I.e As you can use the Valid Address and Valid Data to work out when you need to do a dummy Write for RWM, or you can detect the 0 Address and 0 Data valid states and let the Z80 "DMA steal" for that clock. Also the 65816 can stop on the Clock not some point within 3 clocks like the '02. the COP interrupt line might be useful for when you want to signal the Z80 or have the Z80 call it.
Rudd has shown that it works in a 64 http://www.baltissen.org/newhtm/10to816.htm but he doesn't say which 64. Kisel has shown that except for the SID and VIC the C64C rev e is stable at 4Mhz. Which means the 64 is reasonably loose when it comes to timings. But these are 64s and not 128s ;)
The other "fun" aspect of a 65816 is it want a Phi 2 IN not a Phi 0, so you can probably do some fancy clock work to nudge and shift when you want things to happen. I hope...
I am very surprised about a reported use of illegal opcodes at 50%, so much so I have to ask if you trapped on one of the opcodes or was it possible it was another issue dealing with swapping one processor for another.
On the C128 there is a jumper that is redundant to a trace already on the board for when the Z80 drives the bus, otherwise a noise glitch "stands" on the line. Changing the speed or technology of what drives the bus _could_ have unintended results.
A quick example is NMOS drive low hard but is "softer" on the pull up, banging hard in both directions would be different as would banging soft. One of the issues I had to troubleshoot for was a noise pattern caused by processor activity corrupted some DRAM contents. Since it was caused by noise I couldn't trigger on the processor itself, it went off the tracks hundreds of microseconds after the corruption had occured. if you have heard me tell stories this is when i used a light pen to catch corruption in the video memory and trigger the analyzers to see what the processor was doing at the time of the corruption. Corruption also could look like illegal opcodes if just trapping on them and not checking on whetehr the processor was sane.
If it really is intentional use of illegal opcodes then again I am amazed, we knew about a few and joked about who would use them but no-one I knew in the culture of the time admitted to using them. The exception that comes pre-accepted is copy-protection, we knew those peopel were semi-insane to negine with. They would have to be motivated to use them also given that a standard assembler doesn't support it natively without various tricks.
>I am very surprised about a reported use of illegal opcodes at 50%, so much so I have to ask if you trapped on one of the opcodes or was it possible it was another issue dealing with swapping one processor for another.
Definitely making use of undocumented op-codes. My original suspicion was yet another one of the about 200 odd problems that we had making the damned tower work originally. I double comfirmed a couple of those with VICE (the Wizball loader immediately springs to mind, as does the GEOS64 which makes use of the LAX pseudo-opcode - at least v1.2 I think it was. No idea about others ... we tested, but not *that* exhaustively).
At the end of it, it was just a case of a certain invidual sitting next to me a saying "I told you so" ... (yeah right ... ok ... smart a***).
On a side note regarding op-codes and so forth as it seems applicable here. Later stuff seemed to be *much worse* than earlier. So for example, Commando, which is a C64 title (doesn't work for other reasons but I digress) doesn't use them (as say Theatre Europe), but a hacked version which has been frozen by I am assuming a freezer cart, *does* and so that won't even get past the subsequent load part when it starts decompressing itself.
>On the C128 there is a jumper that is redundant to a trace already on the board for when the Z80 drives the bus, otherwise a noise glitch "stands" on the line. Changing the speed or technology of what drives the bus _could_ have unintended results.
Your "Big Red Wire" (actually, it's white on one a REV6 and black on a REV7 128D boards that I have, but I digress, but yes). On the REV6 board, if you desolder that wire you will find that the unit will fail to boot CP/M on one in every 10 times on power up - really does screw with the Z80. Kevin was rather pedantic on that one. I thought he was pulling my leg until he demonstrated it to me. After that, I went back and listened to one of your old interviews when you mentioned it. I'll say it right now .. identifying that one would have required a certain degree of insanity....
>A quick example is NMOS drive low hard but is "softer" on the pull up, banging hard in both directions would be different as would banging soft. One of the issues I had to troubleshoot for was a noise pattern caused by processor activity corrupted some DRAM contents. Since it was caused by noise I couldn't trigger on the processor itself, it went off the tracks hundreds of microseconds after the corruption had occured. if you have heard me tell stories this is when i used a light pen to catch corruption in the video memory and trigger the analyzers to see what the processor was doing at the time of the corruption. Corruption also could look like illegal opcodes if just trapping on them and not checking on whetehr the processor was sane.
Actually that is a really, *really* good point. We only looked in detail for the first few. If there is crap on either the address bus, or the data bus, then that would not necessarily be reflected correctly on the logic analyzer, so what it is saying, may not actually be what the MPU is actually seeing/acting on, which means that what I was taking as gospel may very well not be correct at all.
We *never* tested anything running at 2MHz in 128 native mode, as we just couldn't get the tower to work even to a point where the damned thing would be stable at all. There are a *large* number of sins committed to make the MPU tower work as it was and it was only ever a bodge to prove a point (albeit to me).
>If it really is intentional use of illegal opcodes then again I am amazed, we knew about a few and joked about who would use them but no-one I knew in the culture of the time admitted to using them. The exception that comes pre-accepted is copy-protection, we knew those peopel were semi-insane to negine with. They would have to be motivated to use them also given that a standard assembler doesn't support it natively without various tricks.
That was my original assumption but in the few that I looked at in a fair bit of detail, the most common of these weird ones were:
A7/AF - "LAX"
87/8F - "SAX"
CB - "AXS"
Now, regardless of whether they "should" be used or not is somewhat moot. The fact is that they *are* used, which means to make something "compatible", we have to re-create that level of insanity, which kind of took the shine off the whole project to me.
That means to mimic those, either I have to re-use a 8502 (which is something that I *really* didn't want to do) .... *or* ... I re-implement the MPU in a FPGA and that would then support said stupidity. I had kinda expected that from the VIC (and the VDC) but I really really didn't want to have to do that with the MPU as well. It is not so much of a case that it can't be done, but rather a case that I really didn't want to have to re-create the CPU.
.. that of course said, I now have on my desk in front of me a tray of Xilinx FPGAs ... so, you can probably where this is heading ...
Feel free to start laughing hysterically about the sanity of said individual.
>On a side note regarding op-codes and so forth as it seems applicable here. Later stuff seemed to be *much worse* than earlier.
That makes sense as I am calibrated for 1985 and then in the closed environment of how engineers think about mass production. With that said I had had a boss before CBM that used to say “the customer is using it wrong”. At CBM I tried to foster an attitude that the customer can use it however they want. To that end I had to put the glitches back in the I/O Select lines and couldn’t move the dot on the “I” in the font rom.
>Your "Big Red Wire" (actually, it's white on one a REV6 and black on a REV7 128D boards that I have, but I digress, but yes). On the REV6 board, if you desolder that wire you will find that the unit will fail to boot CP/M on one in every 10 times on power up - really does screw with the Z80. Kevin was rather pedantic on that one. I thought he was pulling my leg until he demonstrated it to me. After that, I went back and listened to one of your old interviews when you mentioned it. I'll say it right now .. identifying that one would have required a certain degree of insanity....
I got lucky in in that took about an hour to find after a week long fight with my boss. He had assigned someone to fix it as a slap at me and the poor guy didn’t stand a chance, I don’t know that he even picked up a scope probe during that time as I went and got caught up on sleep and showers. (It’s amazing how much you can sleep after weeks of sleep deprecation)
Basically I looked for differences between the two modes and there were enough differences at critical times (/RAS) as I had finally gotten confidence we had the ’02 side tuned (including VIC and DRAMs).
To see the glitch I stared at the screen and then looked up at a white wall and it was (mostly) plainly there. At our last reunion the first words out of Hedley’ Davis’s mouth was “remember that time you said you could see that glitch on the wall” as if it was total BS (he forgot that we actually fixed it that way), but then the first words out of Frank Palia’s mouth, who I hadn’t seen in some 28 years, were “remember when you showed me the glitch on the wall!” (He had taken the time to stare at the scope and then wall) I actually found it in about 30 minutes but continued looking at all lines to see if there were other, possibly worse, issues. Bottom line was that the glitch is actually gone (a standing reflection actually) with the wire in place as there was no end of the trace to reflect off of as now it was a loop.
We did a run of 10,000 that weekend basically to prove that I was full of hot air, that there was no way a wire could actually fix something. Everyone in the department had to participate except the boss hadn’t invited me so I showed up with a case of beer on my shoulder handing them out as the “super line” in production was manned by the R&D staff for two days.
>We *never* tested anything running at 2MHz in 128 native mode, as we just couldn't get the tower to work even to a point where the damned thing would be stable at all. There are a *large* number of sins committed to make the MPU tower work as it was and it was only ever a bodge to prove a point (albeit to me).
Heh, 2Mhz mode is actually easier on the timings then when the VIC is involved. The problem with Faster chips is they don’t hang the data on the line as long for the critical data hold spec (has to hold 5-10ns after Phi goes away)
>That was my original assumption but in the few that I looked at in a fair bit of detail, the most common of these weird ones were:
A7/AF - "LAX"
87/8F - "SAX"
CB - "AXS"
I’ll bet the chip runs slightly hotter internally when doing these.
>Now, regardless of whether they "should" be used or not is somewhat moot. The fact is that they *are* used, which means to make something "compatible", we have to re-create that level of insanity, which kind of took the shine off the whole project to me.
Lol…. Even things that should be safe, getting rid of ghost copies of the I/O space or putting a register where no-one should be writing, or making a font look better, all backfire. Welcome to what was my world, where I had to sacrifice my own self-respect to make it work. (Look at the Z80 clock circuit)
Make a real MMU and you can multitask. :) I didn’t include system only registers and it wasn’t till it was too late that I found that Fred wasn’t using the MMU himself for the Kernal because the user could access what then were the “public” registers (remember there is no wrong way to use it, well there is but you know what I mean)
>FPGA it, you will get more speed and you will be able to simulate waked timing through pipelining delays if needed. Plus the bus termination choices (mouth watering now).
Closely couple some internal RAM in the FPGA to the processor core and go ahead and burst to 50MHZ when running slow isn’t critical. >:)
>.. that of course said, I now have on my desk in front of me a tray of Xilinx FPGAs ... so, you can probably where this is heading ...
I stopped considering Xilinx for heavy hitting when they screwed one of their products up and lied about it for 6 months while they retooled. This really screwed Greg Berlin up in the 90’s as he could have compensated if they had just fessed up and knew new chips were coming, and that the corruption wasn’t his fault. Funny thing is I ran into Greg at VCF last week and he didn’t remember the incident I was talking about, so here I am bearing a grdge on behalf of a friend that had long since forgotten said incident. :)
>Feel free to start laughing hysterically about the sanity of said individual.
Sounds interesting. Go for it. I would love to see an array of mostly compatible systems running in FPGA (NMOS? We don’t need no stinking NMOS.) Hell keyboard controllers runfaster than we did back then, take adantage f it. >:) I have never stopped to think about how much of a 128 could really be pulled into an FPGA but once you don't have to leave the chip for anytging but video and keyboard (and that pesky expansion slot) it gets easier.
What would it take for a C1024 kickstarter where you( and other Commodore alumni ) a.) make a new upgraded 128 and b.) document how you did it and explain the design choices, best practices and how you bug fixed things? So we do a complete PRG with schematic etc like the old days.
A "new" 8bit commodore like the 128 could be a fun learning computer/development tool. If it is all soft cores it can be fiddled with easily. Having both a 6502 and Z80 would give good exposure to different ISAs and how the difference in design plays off on strengths and weaknesses, doing modern CPU is just too hard to get to from 4 bit ALU to 40 stage pipeline, with virtual memory and 4 caches, forget it. you need middle steps.
Maybe ditch the CIAs and put AVRs in their place ( might need to make something else with a Shift register for Burst Mode though ) so the computer becomes an AVR development machine, and you can program against hardware tests rather then the "works fine in the simulator, borks on the actual chip" .
Having a simple well commented Kernal + being able to run the CP/M code gives options and comparisons for OS design.
Being able to slow the machine down to 1Mhz while looking at timing clashes and how the CPUs share the bus etc so people can learn the coding issues with Multithreading and the hardware issues rather than trying to guess what happened in a cache at 2Ghz.
The VIC style of chars + sprites vs the Bitmap + DMA style of the VDC lets you explore and play with the different graphics methodologies.
Documenting the what goes wrong and how to fix is the major part of interest I would think, nothing teaches it, the books all assume everything will go perfect and don't tell you how to fix the wheel falling off. This is something QuiDunki does well. I also documented my more out there faults https://adventuresincpldland.wordpress.com/ ( I've just noticed the typo on the code in one of them ) - the power led is on but it is not on was a doozy.
I would ask the same thing I asked Jeri about the C-1: Isn't that a rather limited market? Who and how many would buy one? In her case she could have sold 100 but she needed 100 to break even.
I think it would be cool to have a big virtual breadboard so to speak that did many of the things you spoke of as a learning aid, you could even have a graphics module that simulates the VDC of your choice, but again how many would sell?
The cool thing about a virtual breadboard where the breadboard is really to supply buses between various megamodules is that if it simulates older computers the busses could really be serial interfaces instead of lots of parallel wires.. :)
Of course with all of that said, you can grab an SOC that does all of that already done and packaged with libraries. :/
The Kickstarter would prove how many would/wouldn't ;)
I would think the Journey is more interesting, a pile of Hackaday posts with, So I had this glitch here but I just couldn't nail it down on the scope. So I made a breakout board and put these dummy wires and a hex buffer on it so I could pick and choose which pins to put a small delay on 3~4 ns enough to see it on the scope and walked around the board to see which chip when put in the breakout made the glitch move and AHA it was the X line on the Y chip and looking at the VHDL, you can see this little latch here that it might be inferring on the chip. Keep on hacking ..
Would be the actual money and "worth" of the project.
If it is mostly 128 compatible then it becomes the 128 Reloaded ( do you know about the 64 Reloaded? ( https://icomp.de/shop-icomp/en/shop/product/c64-reloaded.html - as soon as they are in, they go out of stock that day basically, then some go for stupid money on ebay ). With the 256/512/1024 memory built in should be possible to patch GEOS to use the extra ram in lieu of a GEO/NEORAM module, that will make the GEOS nerds happy, higher clock would help as well. There are also CP/M nerds who argue over the best CP/M machine, so it is 1M and we get it up to Dot Clock ( ~8mhz ) or even 16Mhz then this machine wins that fight. Keeping it retro enough and being made by you would make it "official" and could gain the scene support ( which has grown a lot in the last couple of years, we back to the point where commercial, buy only games are being made and people are thinking of going back to full time hardware dev and repair ), there will be a bunch of neigh say'ers of cause .
When you first start making a module you start with 8 leds and a dip switch and build up from there. Giving people a system where you have a computer wrapped around the machine would make module development a lot easier I would think. The Rasberry Pi are cute but not really that accessible, its all under a huge pile of Linux kernels and smt and ARM in a single chip and that is why 99% are just media centres, there is no "start hardware design kit". Have a simple almost the modern version of 8 LEDS + Dip switch with a keyboard and a 2nd screen with a CPU and I/O that is low level enough that I can prod a single register on a fixed memory location with a POKE 53289,1 makes dev and testing a lot easier I would think. Then I get it working at 1Mhz, I push the machine bus to 2, then 8 and 16 and see where the wheel falls off and then look at why. Flash, Reset, POKE 53289,1, Flash Reset, POKE 53289,1
The problem with the virtual all internal SOC buses is you can't put a scope or LA on them. You are back to Black Box prodding. When you have built the old way with chips on a board then you have some good ideas and know what can go wrong and what to look for, because you put scopes on it back in the day that is cool. When you are following some website or pdf that doesn't tell you anything more, your just starting a windows program that looks like it was made in 92 and not touched since with no ideas or way forward. I would think this would fit that training hole between I made a shift register and the LEDs go 1 then 2 then 3 then 4 and now I need to make a PCI bus card that can handle 1066Mhz FSB or lets put some sensors on a atmega and measure the weather.
Err ... yeah.
Honestly, I really can't for the life me, see this as a viable commercial sort of enterprise. I started on my personal version initially as part of a bet (other party has now died) but it has taken a life of its own now to the point that I want to do it ... for nothing more than the *challenge* of doing it (trust me ... this sucker is *way* more complicated than just creating yet another 6502 computer).
A kickstart .. well ... maybe for a limited production run, but only once say a working prototype is actually up and running.
As has already been suggested to me privately, a better idea may be to use this project as a subject as an ongoing set of videos (the project does lend itself to educational tangents) which may make it worth doing.
To be honest, I never thought that this project would have gathered as much attention as it has. I'm probably going to regret this, but here goes ....
If anyone wants me to throw this open as an ongoing video saga .. speak up now.
You doing a Kickstarter/IndieGoGo, no chance. Bil different kettle of fish.
£155,000+ for this https://www.indiegogo.com/projects/sinclair-zx-spectrum-vega#/ where you can't play most games as you need to press a key( like space ) to get off the title screen
The 64 community has stretched the 64 to the limits at this point, and seems to be looking for the next level, to which the 128 fits, but it needs a bit more.
I've found that there is a blog to go with the Mega65 page which has a lot more info than the landing page which hasn't changed in 3 years. The 65 is a mess.... it has 128K but less usable RAM than the 128, its makes the NOP instruction return from a memory map change, which is done by the MAP opcode, and while you are in the other MAP all interrupts are disabled... It was a design that would have made Jack happy, no extra chips...
I've come up with another way to get a solid speed boost without changing the bus timings. IF we give the 8502 an effective 24bit databus, so it can pull 3 bytes per clock that would drop clock times dramatically.
LDA XXXX <- 2 clocks
STA XXXX <- 2 clocks
BPL XX <- 1 clock
ASL a <- 1 clock
The 8510 is shown to be stable at 4Mhz, I would imagine that the 8502 is also. You would need to put a 3 byte buffer to the data in lines, then while the 8502 wants to read and you have bytes, you run the 8510 at 4mhz during VIC cycle and shift the buffer each time it wants new data. If it wants to write, or needs to get more data you hold the clock until the next 1Mhz rise. Disable the buffer and it will work as per normal.
I wouldn't do videos as such, explaining the gory VHDL bugs and issues on a video is hard, I would think a blog with some videos would be a better way to do it.
> I've found that there is a blog to go with the Mega65 page...
Would that be Paul Gardner-Stephen's blog at
When I go to Australia in September, I will try to contact him for a meet-up.
Fresno Commodore User Group
July 30-31 Commodore Vegas Expo v12 -
C128.com is a owned and maintained by Bil Herd and hopefully one day will attract co-contributors in kind. Find out more about us.
There are currently 0 users online.