SuperCPU128DX MiSTer

[Alynna]

So since I have found out that my contributions are not desired in the original C128 core, I have been trying to figure out how I am going to handle further contributions, and this is the best I can come up with.

I have forked my own fork of the C128 core, so that I will be working on 2 similar cores.

C128 core will have only stuff on it that would be available on or to a C128. This is where I am currently working on 1571 support and hooking up the fast serial lines. It will also be easier for me to sync up with the main C128 core by keeping this one core "pure".

I will also be working on a core called C128DX. This core is going to deviate alot from the C128 and will probably end up more like the C64DX/C65, though in many ways may end up being better. It will not be compatible with the C65 however, since the C65 is still inherently 8 bit and I am increasingly interested in using the WDC 65832 in C128DX.
This is where I will develop the C128 that Commodore should have given us.

I will be backporting anything directly C128 related back to the C128 pure core, such as the 1571, burst moce, etc.

Now I have a roadmap for the C128DX core, and things that it will have and not have in it.

• The C128DX will drop support for the Z80 and CP/M. This is to save LEs for the 85832 and other enhancements.
• The Sound Expander and Digimax support will be being dropped in favor of my own hardware, the 16581 SID Extreme
  [**]https://public.kitsunet.net/832/16581.txt
• The CPU will be transitioned to the 65832, a 32 bit version of the 65816 that was developed by WDC but never released. In 8 bit mode, it will be compatible with the 6510/8502, including timing, but NOT with the illegal instructions.
• The C128DX core will be entirely compatible with the SuperCPU 128 ad SuperCPU 64 (in C64 mode) version 2. I do not expect the current C64/128 cores to adopt the SuperCPU, but there is no small amount of demand for it, and since I an *very* familiar with the 65816, I should be able to produce a core that meets that demand.
• The CPU will have an MMU compatible with the C128, but also extended. That work is obviously already done and working, but I will be expanding it further to be a 32 bit MMU.
• The VIC-II will not be touched to maximize compatibility.
• The VDC on the other hand, WILL be touched.
  [**] An enhanced VDC with CPU mapped registers and RAM, as well as the compatible $D600/$D601 interface, will be developed.
  [**] It will support 320/640/960/1280 * 200/400/600/800 display modes.
  [**] It will support Mono, 16 color, 256 color CLUT with transparent color, and 64k RGB565 and 32k RGBA 5551 color modes.
  [**] It will not support interlaced modes. Modes that were interlaced will now be 25 or 30hz progressive modes. Interlace is the devil.

A full memory map will arrive .. within a week.
Thanks for your patience.

[breiztiger]

thanks for your work a this core !!!

[Chris23235]

This is an interesting project, I am looking forward to the C128DX, the SuperCPU support will give the core some needed software support out of the box. Good idea.

[Alynna]

Since I am working on this in realtime I might as well share the memory map document as I write it.
Comments in the doc are enabled and welcome.

https://docs.google.com/document/d/1Ab9 ... sp=sharing

[AmintaMister]

Great work, keep going!

[eriks5]

So since I have found out that my contributions are not desired in the original C128 core, I have been trying to figure out how I am going to handle further contributions, and this is the best I can come up with.

I never said it was not desired, my apologies if it came over that way. Since you are focusing on new features and extending the C128 beyond it's original features, I thought things might get confusing with development happening under the same core name and in the same thread. That is why I suggested taking the extensions into a separate thread.

As I said before, once I consider "my" version of the core complete, we should look into merging them. But until then there might be changes in my code that could break yours. For example, I discovered the Z80 integration needs to be reworked to get it even near being cycle identical to the hardware. Fixing this might lead to some major changes in some files. I do try to keep these changes to a minimum, also to keep as close to the C64 core as possible. But for now, just getting things right is hard enough without having to worry about breaking your stuff too.

[Alynna]

Alright Well I am working on things like the 1571, would you be ok with me contributing specifically C128 things (like the 1571) to your core directly? I am pretty well versed in Commodore 8-bits and would like to contribute. This is one of the reasons I decided to fork off to a "pure C128 core" so I would have a place to stage such things from, to get them into your core sooner.

[killersquirel]

These are exciting times that we are living in. Thanks to both of you for your work!

[Alynna]

So want to give an update. Right now, I am working on C128 vanilla, because of an essential option I want to put both into C128DX and into eriks's C128 core.

I am expanding the 1541 support to support the following:

• 1571 disks and ROMs
• The fast serial line of the C128

I am NOT splitting 1571 support off into its own thing. I very quickly ran out of registers doing this.
There will be an new option:

Code: Select all

5.25 Drive Type: 1541 | 1571

The hardware I am writing WILL automatically switch ALL 5.25 drives to 1571 mode if a D71 is inserted, or an MFM image is inserted.
Otherwise, for D64/G64, it will follow the 5.25 Drive Type setting.
If you set it to 1541, the drive will be a 1541 in both C64 and 128 modes when *64's are used, and promote itself to 1571 when *71's are used. If there is a mode change, all 5.25 drives will be reset.
If you set it to 1571, it will act like a 1571 in both C64 and 128 modes, and use the fast serial clock (burst mode) in C128 and CP/M modes, regardless of whether you are mounting D64's or D71s.
The default will be 1571, because the 1571 is HIGHLY compatible with 1541 and you will rarely find a case where you can't use the 1571 in 1541 mode in C64 mode.

[eriks5]

I am expanding the 1541 support to support the following:

In the README in the repo you'll find a list "C128 features not (yet/fully) implemented". All these things I'm already working on. Fast serial and 1571 is in that list.

[Alynna]

Well, then I guess I will just wait for it... I thought it would be a thing I could contribute.

[Malor]

eriks5, it seems a terrible shame to leave someone who wants to help and has the skills to do so just sitting on their hands. It's not like FPGA devs grow on trees.

[eriks5]

Alynna was working on SuperCPU support of which I already said I would look into merging that once the vanilla C128 core was feature complete. Apparently they shifted to working on 1571 support, which I am already working on. I don't see how it's contributing by working on something someone else is already working on.

Also, Alynna never checked with me if there was something to work on, just announced to be working on stuff. That's not how collaboration usually works.

And another thing. I started this project for FUN. I *want* to do the C128 and 1571 stuff because it's FUN. Someone just swooping in and taking over the parts I'm working on? Just. no. Go find your own project.

[Alynna]

i'll just wait for your 1571 stuff to release

[Malor]

And another thing. I started this project for FUN. I *want* to do the C128 and 1571 stuff because it's FUN. Someone just swooping in and taking over the parts I'm working on? Just. no. Go find your own project.

That's definitely not how collaboration works.

[Alynna]

I just said I would wait for the 1571 stuff to release...

[LamerDeluxe]

I just said I would wait for the 1571 stuff to release...

I don't think that was aimed at you

[EeDee]

We've been waiting a while for a C128 core and at last someone has taken it on. Be nice to see the full results of his work and then, later on, see where it can be carried on to.
Best of both worlds

[Alynna]

While I am waiting on the completion of the c128 core, I have decided to go ahead and "get my own project".
I should probably make a new thread for it.
Here it is.
https://github.com/alynna/mega65-mister

[Alynna]

So update on this. I am trying to aim to have the following done by the end of the month:
1) At least 8mb of system RAM, possibly alot more, depending on how much eriks5 is willing to cooperate with me on SDRAM layout changes...
I kind of want to lay the SDRAM out like this:

Code: Select all

SDRAM Layout (required 32mb layout - 16MB system RAM):
$00000000-$00FFFFFF 16MB  Core work RAM, Tape, ROMS, etc
$01000000-$017FFFFF 8MB   C128 RAM bank 0-127
$01800000-$01BFFFFF 4MB   C128 RAM bank 128-191
$01C00000-$01FFFFFF 4MB   C128 RAM bank 192-255 and 4MB GEORAM
SDRAM Layout (Optional 64mb layout - 48MB system RAM)
$02000000-$02FFFFFF 16MB  V3 MMU: C128 bank 256-511
$03000000-$03FFFFFF 16MB  16MB REU and C128 bank 512-767
SDRAM Layout (Optional 128mb layout - 112MB system RAM)
$04000000-$07FFFFFF 64MB  V3 MMU: C128 bank 768-1791

The work for this is done. In theory my current MMU can address the entire 4GB 32 bit space, but right now only 1792 (112mb) RAM will be available to the MMU.
2) The 85832 CPU should be entirely replacing t65. The side effects are

• No illegal opcodes will work. They will all have new functions.
• Should be able to run SuperCPU software, but i'm not sure it will be 20mhz ready yet.
• A mode that allows you to work with 32 bit addresses and registers for the max freedom possible.
• Between the MMU bank function capabilities, and the CPU register swapping capabilities, very fast, preemptive multitasking should be possible.

3) Beginning improvements with the VDC:

• All registers exposed at $D100. No more having to play with $D600/$D601
• $D600/$D601 still present for compatibility
• VDC will no longer have its own RAM. Instead it will share RAM with the system, living at bank 127 by default. That means you can access it directly.
  Code to change a byte of VDC RAM:

  Code: Select all

  LDA #40: STA $7f0400  (ML version)
  bank 15:poke MMU+13,127:bank 3:poke 1024,64 (BASIC version) 
  
  32 bit mode code:
  lda #$48492120: sta $7F0000 ; write "HI!" in the left corner of the screen
  

• VDC will be 32 bit aware, and can see its 64kb RAM segment in any available RAM bank. This means register speed page flipping.

Looking forward to all your VDC demos and movie players

[ericgus09]

2) The 85832 CPU should be entirely replacing t65. The side effects are

• No illegal opcodes will work. They will all have new functions.

Wont that break compatibility ?

[Malor]

If you're doing all that stuff, it's not a C128 anymore, it's a fantasy computer that probably won't have any software, unless you write it.

[breiztiger]

As the Spectrum next

[dmckean]

As the Spectrum next

Or the MEGA65.

Some people like fantasy hardware, it's not my thing but I don't see why some like to complain so much about it. Let Alynna make his C128 successor.

[Bas]

Other than "because we can", why would an 8-bit computer have many megabytes of RAM at all? Or to rephrase that: what type of use cases does it enable? I'd say there'd be rapidly diminishing returns after the first megabyte or two as you'd start to feel the rest of the architecture buckle. So.. I'm curious.

[ericgus09]

Or the MEGA65.

Some people like fantasy hardware, it's not my thing but I don't see why some like to complain so much about it. Let Alynna make his C128 successor.

Sure .. though it might be helpful to give this fantasy machine its own designation ala Mega65 .. perhaps the 256C ? .. Its still neat .. and very much a "what if" machine for sure.. Giving it a new name would help set the expectations that its something a bit more/different than a standard 128 ..

[akeley]

It's already called C128DX, which seems enough to differentiate it from the "normal" C128 cores (of which there are now 2 under development).

[ericgus09]

It's already called C128DX, which seems enough to differentiate it from the "normal" C128 cores (of which there are now 2 under development).

Ha apparently not different enough as I, my self, got confused today on the two different threads..

[Alynna]

As the Spectrum next

Or the MEGA65.

Some people like fantasy hardware, it's not my thing but I don't see why some like to complain so much about it. Let Alynna make his C128 successor.

Her, but thank you here

[Alynna]

2) The 85832 CPU should be entirely replacing t65. The side effects are

• No illegal opcodes will work. They will all have new functions.

Wont that break compatibility ?

Only with things that use illegal opcodes. You are trading it for SuperCPU compatibility, though.