SuperCPU128DX MiSTer

[Alynna]

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.

There is a usefulness of this core above and beyond just it being a "fantasy computer".
It is one compatible with the SuperCPU 128, including SuperCPU 64 programs.

The SuperCPU could address 16mb RAM. It got used.

Additionally the new MMU can flip the VDC pages. This means you can flip to another page (with completely different video data) quickly (in a few cycles).

I guarantee the scene coders know what they can do with that.

[Alynna]

I came here to post just to notify that I have been synchronizing with the C128_Mister code.
It takes time because I have to go file by file in VS code, look at my changes and his changes side by side, and decide what to incorporate.

I just threw away my attempt to implement 1571, since he declared he was already doing it.
Most of my current focus has been replacing the CPU with the 85832 (a 8502/65832 hybrid).

[Alynna]

I came here to post just to notify that I have been synchronizing with the C128_Mister code.
It takes time because I have to go file by file in VS code, look at my changes and his changes side by side, and decide what to incorporate.

I just threw away my attempt to implement 1571, since he declared he was already doing it.
Most of my current focus has been replacing the CPU with the 85832 (a 8502/65832 hybrid).

[Alynna]

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..

The reason I called it C128DX, is because the C65 was originally called the C64DX. Since this is a compatible upgrade to a C128, such is the name.

If its really too confusing I could call it the C129...

[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..

The reason I called it C128DX, is because the C65 was originally called the C64DX. Since this is a compatible upgrade to a C128, such is the name.

If its really too confusing I could call it the C129...

Its your baby .. but as careful as I usually am, even I got tripped up by it .. I can just see people downloading it, running it, and assuming its a bog-standard C128 core and having problems .. just a thought to potentially nip an exceptionally annoying pest in the bud before it even happens, I can see every 3rd post being about why XXXX wont run or problems with ZZZZ .. then having to explain exactly what it is .. etc .. etc.. rinse repeat every few days for months, I can easily see this happening quite often to the point of annoyance.

[Malor]

Since you're making breaking changes, calling it C129 might make that clearer. If it was fully backward compatible, then 128DX would make sense, and it wouldn't matter much which core people used. But with a completely different CPU that doesn't duplicate the undocumented opcodes, using a name that's obviously "wrong" might save some folks time. They might even look at the docs.

I imagine many users won't be that hep to old machines, and may not immediately realize that the C128DX didn't exist in real life. That's a pretty obscure detail from 35 years ago, after all....

[LamerDeluxe]

The way I understand it, it would only not be backwards compatible if software used illegal opcodes, which doesn't seem like a big deal to me. And maybe there could even be a menu option to just run it in full C128 mode.

Although that is what the other (C128) core is for. And if you would have a core that is called C128 and one that is called C128DX, it shouldn't be unclear which one is the regular 128.

Actually, now I'm thinking about a scroll text in the MiSTer menu, giving you some short information about your current selection in the core selection list.

[Alynna]

Since you're making breaking changes, calling it C129 might make that clearer. If it was fully backward compatible, then 128DX would make sense, and it wouldn't matter much which core people used. But with a completely different CPU that doesn't duplicate the undocumented opcodes, using a name that's obviously "wrong" might save some folks time. They might even look at the docs.

I imagine many users won't be that hep to old machines, and may not immediately realize that the C128DX didn't exist in real life. That's a pretty obscure detail from 35 years ago, after all....

I'll consider C129 but the "breaking changes" being made are the same kind of breaking changes one would make if they plugged in a SuperCPU 128 (a real device that exists) into the back of their actual C128. So in a sense its a breaking change, but in another, its not. I might rename it to SuperC128, so that people who remember what the SuperCPU is, knows what I am trying to do.

And for those who don't... http://supercpu.cbm8bit.com/ is a start down that road...

[Alynna]

https://www.protovision.games/md/traile ... anguage=en

Here is another example of the kind of application I am trying to support with this port.

[eriks5]

Maybe a good name for this core would simple be "SuperCPU".

[Malor]

Maybe a good name for this core would simple be "SuperCPU".

Perhaps "C128 Expanded"?

[Alynna]

I am going with SuperCPU128DX. I am patching stuff back together after the rename as well.

[breiztiger]

Or C128SUPERCPU more practical for search in menu

[ericgus09]

I still think calling it a "C129DX SuperCPU " might be a better option or something, something that specifically doesn't have 128 in the name .. just kinda avoid the entire "128" thing .. I think you will save yourself a lot of repeated comments explaining what it is and why some copy protected C128 game doesnt work on it ...

Im fascinated by the features you are thinking for this machine and will be eager to try it .. but I think you should make it painfully and obviously clear without any chance for doubt what it is exactly .. its just going to save you a lot of grief and annoyance later on down the road.

[eriks5]

+1 for not having "[C]128" in the name

[fierman]

Removal of illegal opcodes might break the few existing C128-only releases. It could be worthwhile checking your work against productions like these:
https://csdb.dk/release/?id=44983
https://csdb.dk/release/?id=218365

[LamerDeluxe]

Removing C128 from the name makes no sense IMO and would only cause confusion.

[fierman]

Removing C128 from the name makes no sense IMO and would only cause confusion.

If the core would be incompatible with the handful of C128 only releases existing in the wild, naming it C128 would make zero sense.

[LamerDeluxe]

Removing C128 from the name makes no sense IMO and would only cause confusion.

If the core would be incompatible with the handful of C128 only releases existing in the wild, naming it C128 would make zero sense.

That doesn't sound logical to me. But actually I think the end result of both projects should be a single C128 core with SuperCPU and other enhancements being options in the core menu. IMO that would be best for the end user.

[fierman]

If the core would be incompatible with the handful of C128 only releases existing in the wild, naming it C128 would make zero sense.

That doesn't sound logical to me.

See:

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.

There are less than 200 known C128 only programs, of which the handful really interesting ones use most likely illegal opcodes.

[Alynna]

Removing C128 from the name makes no sense IMO and would only cause confusion.

If the core would be incompatible with the handful of C128 only releases existing in the wild, naming it C128 would make zero sense.

That doesn't sound logical to me. But actually I think the end result of both projects should be a single C128 core with SuperCPU and other enhancements being options in the core menu. IMO that would be best for the end user.

It is almost certain I will never see my changes introduced to the standard C128 core.

[Alynna]

If the core would be incompatible with the handful of C128 only releases existing in the wild, naming it C128 would make zero sense.

That doesn't sound logical to me.

See:

Wont that break compatibility ?

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

There are less than 200 known C128 only programs, of which the handful really interesting ones use most likely illegal opcodes.

The use of illegal instructions wasn't as common as this insinuates, especially in C128 specific programs.
On the other hand, there are quite a few programs out there that were either enhanced with, or straight up require, a SuperCPU.
Many people never got the option to own a SuperCPU, well now they could.

Also the name SuperCPU128DX is firm. I've already refactored once. The core is a C128 with a SuperCPU and other improvements, like gobs of RAM.
Even the product itself was called the SuperCPU128 (there was a SuperCPU64, but I don't see the need to do this since the SCPU128 is entirely compatible with the SCPU64, it'd basically be doing the same work twice).

[Malor]

That's pretty clearly not a regular C128, so any further name changes would probably be silly. Plus, yours is probably the most descriptive option so far. Folks will know exactly what they're getting.

[Alynna]

Most the work is done and it is booting (not correctly) on the 85816 CPU, in that you can tell its definitely executing instructions.
Currently I believe the issue is that, the 65816 has a ready out signal, as well as a VPA/VDA signal, to tell the outside world that what's on its address bus is OK and that its ready to proceed.

The current code does nothing to respect this and I am trying to find the best way to tell the main part of the hardware to wait on the next 'ready' state.

With the current state machine I think I can hit 16mhz. Once I reach that, I will bump the main clock to 64mhz, and widen the state machine a little.

[Alynna]

Current awesome challenges:
The 65816 has a ready output that must be respected. I am trying to find the best place to cycle-stretch so that the rest of the core is accessing the CPU only when rdy_out is high.

The 65816 has no NMI_ACK signal. I'm trying to fake it for the cartridge port.

[Malor]

I'm pretty sure I read that the main reason the 8-Bit Guy from Youtube didn't use the 65C816 in his Dream Computer was because that chip multiplexes its pins; first they select an address, and then they change to reading or writing data. IIUC, it was trying to fit a 16-bit chip in the same pinout as the 6502, and the mighty morphing power pins made the support circuitry much more difficult to implement, and may have contributed to its relative unpopularity vis-a-vis the 68000, which AFAIK was pretty straightforward.

I don't know how much of that you'll need to do on the FPGA, since you can add any pins you want, but it could make the clock cycles a little tricky.

[Alynna]

I am so very close now.
Almost all issues can be traced to NMI handling now. I need to extend a path into the 65816 to get a proper NMI acknowledgment signal. I will take some screenshots...

[Alynna]

40 column. 85816 CPU. Starts up. No cursor, no keyboard, but it is started.

vlcsnap-2022-08-08-22h31m29s696.png (83.17 KiB) Viewed 6857 times

One key responds. Restore.

vlcsnap-2022-08-08-22h32m16s002.png (133.32 KiB) Viewed 6857 times

I believe all I need to do is debounce NMI.
Its only a matter of time now.

[Alynna]

What I surmise is currently happening is that theres an NMI_ACK signal the rest of the core wants, but there is no natural NMI signal acknowledgment pin from the 65816.

However I have found the signal NMI_SYNC inside the CPU, which I believe I can expose to the rest of the core to give it an NMI ACK. We'll see soon enough.

[ericgus09]

However I have found the signal NMI_SYNC inside the CPU, which I believe I can expose to the rest of the core to give it an NMI ACK. We'll see soon enough.

And there in lies the magic of FPGA..