Commodore 128 for the MiSTer?

[lroby74]

OMG!
I love you!! Thanks from deepest of my heart!

I recently got myself a DE10 nano and saw there was no C128 core, so I figured this is a nice little project to get back into FPGA programming

The C128 was my second computer back in the eighties - traded in my C64 for it - and I loved it, and still do. I still have it, and though it needed some repairs over the years it's still functioning. But I'm always afraid to turn it on, as it might just die some day.

So, I dove in schematics, Programmer's reference guide, and even some books I still had from over 35 years ago, in an attempt to create a C128 core, and here it is. Forked from the C64 MiSTer core since the 128 is essentially a C64 with some extra chips hacked in. Not a 100% complete C128 implementation (yet), but some programs already work.

C128 features implemented

• MMU fully implemented and tested. Configurable for 128K or 256K of system memory.
• VDC partially implemented: memory interface is, video output is not.
• Z80 implemented. Simple uses work, but CP/M does not yet boot.
• C64 mode fully operational.
• Support for C128 specific .CRT and .PRG files.
• C128DCR or C128 ROMs and hardware differences implemented.

C128 features not (yet) implemented

• C128 specific keys
• 80 column display
• CP/M mode
• Loading internal function ROM (were there even any ROMs for this?)
• 1571 drive and fast serial for disk I/O
• ... probably other stuff I forgot or didn't realize is different from the C64

You can download the core from the repo at: https://github.com/eriks5/C128_MiSTer
The README of the repository has some more information on what is working and what is not.

And here's a short YouTube video showing the current state: https://youtu.be/DoZKi4JNWWs

I will be continuing to work on this. Next thing I want to dive into is implementing the extra keys and the 80 column video output.

[jalbarracin]

Wow!! this is wonderful news

[yellperil]

This is awesome! This may be asking too much, but is it possible to implement a dual monitor option.

LIke one display to HDMI and one to VGA connector on the I/O board ( user configurable ).

I will be continuing to work on this. Next thing I want to dive into is implementing the extra keys and the 80 column video output.

[Juri]

thank you so much man!, you make my day!!!!!

[eriks5]

This is awesome! This may be asking too much, but is it possible to implement a dual monitor option.

LIke one display to HDMI and one to VGA connector on the I/O board ( user configurable ).

This is something I was thinking about too. Dual monitor would definitely be the most correct way of implementing it, but I have no idea if this is even possible with the MiSTer.

[ron]

Rememotech MTX core use dual screen, TTY Console Screen for CP/M and VPD 991X.

Here is the source, this is a nice sample of dual screen on MiSTer:
https://github.com/RW-FPGA-devel-Team/Rememotech-Mister

Cheers

[Alynna]

A turbo mode that allow the 8502 and Z80 to live outside of eachother's bus occupation time a little more (4mhz 8502/8mhz Z80), primarily to enhance CP/M speed

Changing from the current serial coprocessing model to true multiprocessing would be a huge change to the hardware and also requiring major changes to the Kernal and Z80 Bios. Currently the whole system expects only one CPU to run and the other waiting to be allowed to continue. There's already enough room in the core timing to have them run in parallel at 2MHz each, but the result would not be a C128 anymore.

Dual SID should be able to be done with the second SID in the D4xx memory space (like $D420?)

Yes that's already one of the four available options inherited from the C64 core. $D500 is still in that list but won't work in this core right now. It just needs to be removed from the menu and right SID selection logic adjusted.

Oh I wasn't talking about having the CPUs running at the same time, I was talking about giving the Z80 2x the clock cycles during its time on the bus so that it could reach actual Z80 speeds. I know running them at the same time would never work

[djsquare]

Sounds like we'll be able to try out Attack of the PETSCII Robots for the C128 very soon. Amazing work!

[eriks5]

Sounds like we'll be able to try out Attack of the PETSCII Robots for the C128 very soon. Amazing work!

That already works, I even demonstrate it in the YouTube video

Except the map on the VDC screen, since that's not implemented yet.. soon

[eriks5]

Oh I wasn't talking about having the CPUs running at the same time, I was talking about giving the Z80 2x the clock cycles during its time on the bus so that it could reach actual Z80 speeds. I know running them at the same time would never work

Since the C64 core can already run the 6510 at 4 MHz, I think that's a single line code change. I removed turbo speed selection from the options menu for now, but once the "standard" C128 stuff is all good, it's hopefully coming back.

[eriks5]

Rememotech MTX core use dual screen, TTY Console Screen for CP/M and VPD 991X.

Here is the source, this is a nice sample of dual screen on MiSTer:
https://github.com/RW-FPGA-devel-Team/Rememotech-Mister

Cheers

Thanks for the pointer, will definitely look at that core to see how they do it. But initially it'll have to be screen switching because I can't test multiple outputs as I haven't received the Ironclad board yet and I only have the DE10 HDMI output to test with.

[eriks5]

New version released on GitHub.

I'll let these images speak for themselves

The README documents what is implemented and what is not yet: https://github.com/eriks5/C128_MiSTer/t ... 56x#readme

[virtuali]

WOW, that's impressive.

[AmintaMister]

Super!!!

[Goingdown]

This is great! I was able to boot CP/M, but keyboard does not work. Just switched to 80col mode, booted with CPM (I tried with cpmf3-1.d64 disk which is modded CP/M fast for c128) and it booted correctly.

By the way, can D71 disk format be supported? There is quite a lot disks in that format especially for CP/M.

[eriks5]

This is great! I was able to boot CP/M, but keyboard does not work. Just switched to 80col mode, booted with CPM (I tried with cpmf3-1.d64 disk which is modded CP/M fast for c128) and it booted correctly.

By the way, can D71 disk format be supported? There is quite a lot disks in that format especially for CP/M.

Interesting. I haven't been able to get CP/M booting, but I only tried a .d81 disk image, that might be the difference. Can you point me to the .d64 image you used? I know the Z80 memory map is not entirely correct right now, which might cause the keyboard issue. I clearly need to do some debugging there.

1571/d71 support is planned, but haven't looked at how drive emulation works in the MiSTer at all yet.

[Goingdown]

Interesting. I haven't been able to get CP/M booting, but I only tried a .d81 disk image, that might be the difference. Can you point me to the .d64 image you used? I know the Z80 memory map is not entirely correct right now, which might cause the keyboard issue. I clearly need to do some debugging there.

I used CPMfast Final package... cpmf3-1.d64 is disk image name, I think I downloaded it from http://www.zimmers.net/anonftp/pub/cpm/ ... tfinal.zip

I tried with other D64 CP/M versions as well but all of them have same problem with keyboard.

[Alynna]

OK I finally got this downloaded (from the github) and are building it from source, and I will be working on developing this. I pulled my own fork but if you want me to contribute directly to the repo, my name is "alynna" on github.

I have not attempted CP/M yet, and I am studying the source so I can attempt fixes on my own but I have observed the following issue:
Specifying a drive ROM appears to do nothing. We should consider restoring the 1541/1581 options from the C64 core (they each have their own selection boxes)

One feature i'd like to implement right away is a way to specify the startup mode, of 3 choices, C128 40 column (normal), C128 80 column (40/80 key down) and C64 (C= key down at start, or some other earlier go64 hook, theres actually a vector we can call for it)

[Alynna]

I have noticed that BMC128 on raspberry pi (Bare metal C128) also has issues with keyboard not working in CP/M. The issues could be related...

[eriks5]

OK I finally got this downloaded (from the github) and are building it from source, and I will be working on developing this. I pulled my own fork but if you want me to contribute directly to the repo, my name is "alynna" on github.

Keep in mind that this is very much a work in progress. I'm both learning to understand the finer details of the C128 itself and learning FPGA programming. So there might be refactoring or major overhauls to come.

Specifying a drive ROM appears to do nothing. We should consider restoring the 1541/1581 options from the C64 core (they each have their own selection boxes)

C64 core updates 1541 ROM as part of the Kernal ROM. There's also a separate Drive ROM upload option, which I initially assumed to do the same. But it looks like the Drive ROM option only updates 1581 ROM (haven't confirmed this). I'll look into this when I start with the drive stuff because there is more that needs to be done, like MFM support, .d71 image support and fast serial.

One feature i'd like to implement right away is a way to specify the startup mode, of 3 choices, C128 40 column (normal), C128 80 column (40/80 key down) and C64 (C= key down at start, or some other earlier go64 hook, theres actually a vector we can call for it)

Forcing C64 mode is as simple as making the MMU initialize z80_n and c128_n to 1 instead of 0. I already had booting directly in C64 mode in one of my earliest builds as that was the only working mode. I debugged the MMU from C64 mode initially. The input signals to make the MMU do this are still there (osmode and cpumode)

I have noticed that BMC128 on raspberry pi (Bare metal C128) also has issues with keyboard not working in CP/M. The issues could be related...

Latest commits fix keyboard in the CP/M mode. It was indeed because of the incomplete Z80 memory map. There is one other issue still left in Z80 mode that I want to fix before releasing a new .rbf

[Alynna]

I have a few things to add.
I did get the 40/80/C64 mode selector working.
I fixed a bug where the "Standard" roms selected gave you the C128DCR ones and vice versa.
I still haven't had luck getting drive ROMs to load. Only the stuff that is provided in the core seems to ever come up.

On the side I am working on adding the 65816 instruction set to it with the 8502 glue needed to make it work. This is a road to SuperCPU support and I believe it can be backported to the C64 as well.

[Alynna]

I am thinking we should refactor some of the rom code so one file contains C64 roms, one file contains C128 ROMs, and 1 file contains drive roms.
Also are you on the MiSTer Discord someplace?

[eriks5]

I fixed a bug where the "Standard" roms selected gave you the C128DCR ones and vice versa.

I checked and ROMs are correct in my latest version. I verified checksums according to http://www.zimmers.net/anonftp/pub/cbm/ ... OMs.readme
and I get the checksums for rev.1 when DCR is selected and rev.0 when standard is selected.

The released 20220606 RBF is missing the standard ROMs because I had them commented out because I needed RAM cells for SignalTap during debugging. That version always has DCR roms selected no matter what you choose in the menu, because the ROM images are missing in the build.

I did get the 40/80/C64 mode selector working.

After thinking a bit about this, I don't see the point in having a C64 mode selector. Just load the C64 core if you want a C64. 40/80 column selection could be useful, but doesn't add much either. Since status bits are almost full, I want to reserve these for more important features.

I am thinking we should refactor some of the rom code so one file contains C64 roms, one file contains C128 ROMs, and 1 file contains drive roms.

ROMs are currently grouped the same way as on a real 128 with 256kbit roms, making it easy to load ROMs from zimmmers.net, with one exception for the charrom I merged with ROM14 to save on yet another menu option. I agree there needs to be an easier way to load ROMs instead of the multitude of options now in the menu, and I have a plan for that.

For now I'll keep working on my version of the core. Once I consider mine complete, I'll look into your proposals and changes.

[Juri]

HI, on Ajazz AK33 keyboard the right alt key (should be altgr?) do not work as expected, so is not possible to access 40/80 culumns switch and all keys associated to the altgr key+function keys, i can switch display only using menu since this keyboard do not have numeric keypad. may be possible to fix it please?
thanks

[eriks5]

HI, on Ajazz AK33 keyboard the right alt key (should be altgr?) do not work as expected, so is not possible to access 40/80 culumns switch and all keys associated to the altgr key+function keys, i can switch display only using menu since this keyboard do not have numeric keypad. may be possible to fix it please?
thanks

If you see 80 col switching in the menu, keyboard is not implemented in that version. The latest released RBF does not have keyboard implemented yet. There's one more fix I want to make before releasing a new RBF

[rhester72]

I have noticed that BMC128 on raspberry pi (Bare metal C128) also has issues with keyboard not working in CP/M. The issues could be related...

I'm one of the maintainers...please post a Github issue on this. I'm unaware of CPM keyboard issues with BMC128 (outside of special keys not well handled by a C64 keyboard mapping).

[Alynna]

I fixed a bug where the "Standard" roms selected gave you the C128DCR ones and vice versa.

I checked and ROMs are correct in my latest version. I verified checksums according to http://www.zimmers.net/anonftp/pub/cbm/ ... OMs.readme
and I get the checksums for rev.1 when DCR is selected and rev.0 when standard is selected.

The released 20220606 RBF is missing the standard ROMs because I had them commented out because I needed RAM cells for SignalTap during debugging. That version always has DCR roms selected no matter what you choose in the menu, because the ROM images are missing in the build.

I did get the 40/80/C64 mode selector working.

After thinking a bit about this, I don't see the point in having a C64 mode selector. Just load the C64 core if you want a C64. 40/80 column selection could be useful, but doesn't add much either. Since status bits are almost full, I want to reserve these for more important features.

I am thinking we should refactor some of the rom code so one file contains C64 roms, one file contains C128 ROMs, and 1 file contains drive roms.

ROMs are currently grouped the same way as on a real 128 with 256kbit roms, making it easy to load ROMs from zimmmers.net, with one exception for the charrom I merged with ROM14 to save on yet another menu option. I agree there needs to be an easier way to load ROMs instead of the multitude of options now in the menu, and I have a plan for that.

For now I'll keep working on my version of the core. Once I consider mine complete, I'll look into your proposals and changes.

New cores have 128 bit status fields and I think I can get us switched over to that easy enough. I'll work on that today.

[eriks5]

New cores have 128 bit status fields and I think I can get us switched over to that easy enough. I'll work on that today.

Good to know. But for now, keeping as close as possible to the C64 core is more important, so unless that core changes to a 128-bit status, it's not a priority

[Alynna]

New cores have 128 bit status fields and I think I can get us switched over to that easy enough. I'll work on that today.

Good to know. But for now, keeping as close as possible to the C64 core is more important, so unless that core changes to a 128-bit status, it's not a priority

I think the systems are compatible with each other but I'm doing a build to confirm.
I have updated sys to the latest (that build works perfectly) and moved status bits I am using to 96-127

[Alynna]

Yeah, I have confirmed they are compatible.
I have kept the C64 mode start in there for now and the mode status bits are at 96:97. I have also made a debug menu for other stuff I am working on. I have taken great care to make sure that none of the logic for the new options is followed if the option isn't on.

CPU: 8502/85816 is one of the current options. It doesn't work at the moment (doesn't seem that the signal to turn it on makes it to t65)
Once this is working SuperCPU 64/128 applications.. may work (might need some 65816 instruction work? Support is already in t65 so this doesn't cost us anything) or maybe everything is perfect and it all work.

Coming are:
VDC registers exposed at $D680 (on/off)
VDC RAM exposed (No, In Bank 3, at FE0000)

This will allow direct access to the VDC registers and RAM for a new class of high rez applications