SuperCPU128DX MiSTer

[917k]

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

You do great work but perhaps you could consider staying in your own thread. You asked Alynna to make her own thread, which she did but now you keep coming into her thread making comments which frankly seem a little bit negative.

[CartoonDonkey]

Would it be possible, if re-writing huge bits of the C128, to include a mode that would display 80 columns on a standard 1084s crt? I always thought it was a huge shame to be limited to having to have a special monitor for 128 stuff back in the day. I'm sure it's a hardware limitation of the number of lines the crt can display but still...

[eriks5]

Would it be possible, if re-writing huge bits of the C128, to include a mode that would display 80 columns on a standard 1084s crt? I always thought it was a huge shame to be limited to having to have a special monitor for 128 stuff back in the day. I'm sure it's a hardware limitation of the number of lines the crt can display but still...

The MiSTer's video scaler takes care of converting video output, so it should already be possible to view the 80 column mode on a standard TV/CRT with the MiSTer.

The real C128 has a monochrome signal that is PAL/NTSC compatible so any standard monitor back in the day could show the 80 column mode in B/W.

[mparson]

The 128 didn't need a special monitor so much as the 128 & Amiga just used fundamentally different video formats. The 128's 80-column mode was RGB-I (Digital RGB) and the Amiga was usually doing Analog RGB.

The Amiga's 23 pin video port actually did supply RGBI signals on certain pins and a properly wired up cable would let you use an Amiga on a C= 1902 monitor (the one C= marketed for the 128), but you would have had the limitations of the RGB-I signal, namely, 16 colors. The RGBI signal the 128 used was the same as IBM CGA and you could use the 1902 monitor on a PC with a CGA card as well as use a CGA monitor as the 80-column display for the 128. The advantage of a monitor like the 1902 was that it had both RGBI *and* Luma/Chroma 40 column analog input that you could swap between with the push of a button (or was it a flick of a switch? Been a while, I don't really remember).

As mentioned above, the 128 did also provide a composite B/W 80 column signal on pin 7 of the 9 pin RBI connector. Wire it to the center of an RCA coax and the shield to ground, you'd get a very sharp black and white picture on just about any composite video monitor.

In any case, all of the above only applies to real hardware, not the stuff implemented on the MiSTER.

[Alynna]

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

You do great work but perhaps you could consider staying in your own thread. You asked Alynna to make her own thread, which she did but now you keep coming into her thread making comments which frankly seem a little bit negative.

I do appreciate the defense here, but I really don't want to scare eriks5 away from my thread. Ultimately I want to be collaborating, and negativity isn't really conducive to that.

The name is what it is now, its a pain in my butt to keep changing it.

[Alynna]

There isn't much news to give for an update. I found out that my timing issue is more than just the IRQ/NMI conflict. I am currently using the 65816 core from the SNES, but it does not seem to have the same timing as the SuperCPU did. The easiest way for me to resolve this is to give the SNES CPU the same timing as the 8502 for its instructions but that's actually going to take a bit.

What I do want to add to this thread, however, is to keep in mind that the VDC in the SuperCPU128DX, will have its compatible registers at D600/D601, but also the same set of registers fully exposed to the CPU, and extended registers, at $D100. It will be able to output 320/640/960/1280 x 200/400/600/800 modes, in 1/4/8/16 bit color modes. It will have the option of doing these in interlace or fully progressive modes as well.

Plus there will be a blitter to move data to it, and since the VDC will be able to be mapped to any of the multiple megabytes (currently 8mb) of memory available (its memory will be directly accessible to the CPU) it will become a MUCH more capable video chip.

PS: The Fully 24bit MMU is fully implemented. You can:

• Access up to (currently) 8mb memory. This will eventually be 16mb, as soon as eriks5 is willing to talk about what memory is used where in the SDRAM. I don't want to desync too much from how memory in the SDRAM is used, since that will just make more changes I need to keep up with when I sync with his codebase..
• Page any of that memory in on the MMU's page 1, 2 or 3. Not 0, page 0 must always be page 0.
• With some tricky BASIC programming, it is possible to change page 1 in a way that allows you to *swap out all of your variables* since C128 BASIC keeps all of its variables in page 1. However unless you are willing to copy memory around with assembler side routines, I do not recommend swapping page 1 around while using BASIC, as your variables will either go away or be corrupted.

[Alynna]

It would be nice if an administrator could rename this thread... I'd like to name it:
SuperCPU128DX MiSTer

[Alynna]

I should reiterate that it's important to track this document for updates on capabilities, as well as see the official memory map i'm attempting.
https://docs.google.com/document/d/1Ab9 ... emyDk/edit
Right now I am not implementing the full 32 bit modes and bus, this will be far easier to do once many of the other features are done.
Getting to full SuperCPU compatibility is priority 1, and then expanding that to 32 bits is last priority, since just going to 16 bits is already going to rock your worlds, and allow people to run things like GEOS/Wheels, Doom, and other things that run on the SCPU.

[ericgus09]

run things like GEOS/Wheels, Doom, and other things that run on the SCPU.

Well I can say from personal experience that running Geos at 48mhz on the Ultimate 64 is a surreal experience, having full access to a higher display modes will be VERY INTERESTING for sure..

Looking forward to it..

[Malor]

Would it be possible, if re-writing huge bits of the C128, to include a mode that would display 80 columns on a standard 1084s crt? I always thought it was a huge shame to be limited to having to have a special monitor for 128 stuff back in the day. I'm sure it's a hardware limitation of the number of lines the crt can display but still...

To add to the answer upthread, the 1084S had three modes you could access with a sliding switch; analog RGB (for the Amiga), digital RGB (which supported the 128 in 80-column mode, and I *think* CGA signaling as well), and composite. (edit: I'm confused about whether it supported SVideo; I remember separate chroma/luma RCA jacks, but I'm not sure if that's full SVIdeo or not.)

It seems likely that any 80-column core will end up outputting analog RGB, just mapping the digital signal onto the standard analog output. You'd be using the "wrong" switch on a 1084S, but it should look fine. Whether actual digital output could happen is something I can't answer. It would probably take a different DirectVideo cable, however, as I'm pretty sure the 1084S takes digital input on different pins.

edit: mparson kinda covered that last bit.

[Alynna]

I am thinking of temporarily rolling back to 8502 to get some more features implemented. I recently bought a USB oscilloscope to analyze the problem with 85816 (It boots, the C128 screen shows up, but IRQ timing is really messed up, really no change in status there) and without a SuperCPU 128 to compare to, i'm making educated guesses as to what it *should* be doing...

One of the things I am looking at doing is implementing the SD2IEC. I *do* actually have one of those.

Eventually I am going to have to remove some features to make room for more interesting things. Here's some of the things that could be on the chopping block, and i'd like to know what people would be OK with having scrapped:

[*] The Z80 CPU - personally I am all for this. As long as we have a core that does the Z80 (which we do, C128_Mister). We don't really need 2 cores that do the Z80 since it has very few compelling use cases. Even less than the SuperCPU does, really.
[*] The tape drive. Seriously, what C128 and SuperCPU software came on tape?
[*] The digimax and sound expander. Seriously, I am planning an enhanced SID that will do everything those chips do in a more SID way. (D4xx is filled with registers )

[LamerDeluxe]

One of the things I am looking at doing is implementing the SD2IEC. I *do* actually have one of those.

That would be really nice, there has been a lot of talk recently about SD2IEC support for the Commodore cores.

[Alynna]

One of the things I am looking at doing is implementing the SD2IEC. I *do* actually have one of those.

That would be really nice, there has been a lot of talk recently about SD2IEC support for the Commodore cores.

If/When I end up working on it, expect that it will use the "Secondary SD card" interface, and the code to run it taken straight from the SD2IEC project. That should make it pretty straightforward to implement.

I should note that I have currently started a new job, so I am not doing a whole lot of work on stuff right now, but I want to keep this project alive, which is why I am thinking of rolling back the 65816 to put 'easier' things into the core. I welcome other contributors as well,

[Alynna]

Since this would be relatively straightforward to add as well (the code already exists for it and it doesn't require me to figure out the IRQ interfacing) I have this on the boilerplate as well, and it might even come before 65816 support...

Code: Select all

$D680 ------------- SuperCPU128DX "Krystal" SuperFX chip from SNES -------------------
		(SNES ADDRESS)
$D680 2	R0	$3000	Default source/destination register
$D682 2	R1	$3002	Pixel plot X position register
$D684 2	R2	$3004	Pixel plot Y position register
$D686 2	R3	$3006	For general use
$D688 2	R4	$3008	Lower 16 bit result of lmult
$D68A 2	R5	$300A	For general use
$D68C 2	R6	$300C	Multiplier for fmult and lmult
$D68E 2	R7	$300E	Fixed point texel X position for merge
$D690 2	R8	$3010	Fixed point texel Y position for merge
$D692 2	R9	$3012	For general use
$D694 2	R10	$3014	For general use
$D696 2	R11	$3016	Return address set by link
$D698 2	R12	$3018	Loop counter
$D69A 2	R13	$301A	Loop point address
$D69C 2	R14	$301C	ROM address for GETB, GETBH, GETBL, GETBS
$D69E 2	R15	$301E	Program Counter
------------------Control Registers------------------------------------------------------
$D6A0 2	SFR	$3030	Status flag register (R/W)
$D6A2	1	ICBR	SC128	Instruction cache bank register (0-15) (R/W)
$D6A3 1	BRAMR	$3033	Backup RAM register (W)
$D6A4 1	PBR	$3034	Program bank register (R/W)
$D6A5 1		$3035	Unused	
$D6A6 1	ROMBR	$3036	ROM bank register (R)
$D6A7 1	CFGR	$3037	Control flags register (W)
$D6A8 1	SCBR	$3038	Screen base register (W)
$D6A9 1	CLSR	$3039	Clock speed register (W)
$D6AA 1	SCMR	$303A	Screen mode register (W)
$D6AB 1	VCR	$303B	Version code register (R: $80 on SuperCPU128DX)
$D6AC 1	RAMBR	$303C	RAM bank register (R/W) (Read only on SNES)
$D6AD 1		$303D	Unused	
$D6AE 1	CBR	$303E	Cache base register (R: $D700 on SuperCPU128DX)
$D700 256	INSC	$3100 Instruction Cache (512 bytes unbanked on SNES, 4096 bytes banked on SuperCPU128DX)

[LamerDeluxe]

One of the things I am looking at doing is implementing the SD2IEC. I *do* actually have one of those.

That would be really nice, there has been a lot of talk recently about SD2IEC support for the Commodore cores.

If/When I end up working on it, expect that it will use the "Secondary SD card" interface, and the code to run it taken straight from the SD2IEC project. That should make it pretty straightforward to implement.

I should note that I have currently started a new job, so I am not doing a whole lot of work on stuff right now, but I want to keep this project alive, which is why I am thinking of rolling back the 65816 to put 'easier' things into the core. I welcome other contributors as well,

Using the secondary SD card for it sounds like a good idea. Then you could even share a card between MiSTer and SD2IEC hardware.

A new job often uses up a lot of energy. Thanks for keeping the project alive.

[Alynna]

Due to the VDC sharing main memory on the SCPU128DX, it would be possible to use the SuperFX chip with both the VIC and the new VDC.

[Caldor]

If you get the SD2IEC to work for this core, would a similar solution not also work for the C64 core?

[Alynna]

If you get the SD2IEC to work for this core, would a similar solution not also work for the C64 core?

Yes, it can be backported.

[Grumpy-Old-Gamer]

Wouldnt a cycle accurate 6510 accelerator like seen on the Turbo Chameleon be a better idea. That works with a lot of software with no issues and nice gain in performance even better than the SCPU

[Juri]

sorry for the stupid question, what's the use in having an SD2IEC support in commodore cores, isn't D64/D71/D81/tape more than sufficient?
thanks

[ericgus09]

sorry for the stupid question, what's the use in having an SD2IEC support in commodore cores, isn't D64/D71/D81/tape more than sufficient?
thanks

Only use case I can see right now is for people who want to play with that new CommodoreOS ..

[LamerDeluxe]

sorry for the stupid question, what's the use in having an SD2IEC support in commodore cores, isn't D64/D71/D81/tape more than sufficient?
thanks

It is discussed in detail in this thread viewtopic.php?p=61851#p61851
In the post I linked I explain why SD2IEC could be useful to improve the ease of loading games on the VIC-20 core.

[Malor]

From a 10,000-foot overview, it seems like the SD2IEC is doing the same thing that the Mister is already doing, just with a different interface. If someone implements it, it might be nice to have a toggle to either send the commands out the SNAC port, or else redirect them to the existing drive code. That way, you can either provide a real SD2IEC or a virtual one.

Depending on how that's implemented, however, the complexity of trying to support two drive interfaces at once could be gnarly. I bet there are a ton of corner cases lurking. Like, when you mount a drive, do you expose it both the normal way and as IEC? Do you keep IEC separate? If so, preventing the IEC code from connecting to the same disk the regular code is using would probably be important. And that's just the surface; it seems like there's a lot that could go horribly wrong. External IEC only is likely to be a lot simpler.

[Grumpy-Old-Gamer]

From a 10,000-foot overview, it seems like the SD2IEC is doing the same thing that the Mister is already doing, just with a different interface. If someone implements it, it might be nice to have a toggle to either send the commands out the SNAC port, or else redirect them to the existing drive code. That way, you can either provide a real SD2IEC or a virtual one.

Depending on how that's implemented, however, the complexity of trying to support two drive interfaces at once could be gnarly. I bet there are a ton of corner cases lurking. Like, when you mount a drive, do you expose it both the normal way and as IEC? Do you keep IEC separate? If so, preventing the IEC code from connecting to the same disk the regular code is using would probably be important. And that's just the surface; it seems like there's a lot that could go horribly wrong. External IEC only is likely to be a lot simpler.

The issue with the SD2IEC it's not a true 1541 drive emulator so doesn't handle fast loader's or protected disks
Hopefully with some work the 1541 emulation on MiSTer can be as good as the other FPGA C64 devices, there is early G64 support added already

[Caldor]

From a 10,000-foot overview, it seems like the SD2IEC is doing the same thing that the Mister is already doing, just with a different interface. If someone implements it, it might be nice to have a toggle to either send the commands out the SNAC port, or else redirect them to the existing drive code. That way, you can either provide a real SD2IEC or a virtual one.

Depending on how that's implemented, however, the complexity of trying to support two drive interfaces at once could be gnarly. I bet there are a ton of corner cases lurking. Like, when you mount a drive, do you expose it both the normal way and as IEC? Do you keep IEC separate? If so, preventing the IEC code from connecting to the same disk the regular code is using would probably be important. And that's just the surface; it seems like there's a lot that could go horribly wrong. External IEC only is likely to be a lot simpler.

The issue with the SD2IEC it's not a true 1541 drive emulator so doesn't handle fast loader's or protected disks
Hopefully with some work the 1541 emulation on MiSTer can be as good as the other FPGA C64 devices, there is early G64 support added already

Only early G64 support? Its not full G64 support?

[Alynna]

OK the most interesting use case, and why I want to implement it, is because the SD2IEC supports the .dnp "CMD partition" style file system that supports up to 16mb filesystems. Its not just useful for CommodoreOS but also for GEOS 3.3, Wheels, and a number of other things.
In fact, like the CMD-HD, the SD2IEC is capable of exposing up to 254 .DNP partitions, offering up to 4gb of direct access storage at any given time.

The following screenshot is an example of what can be done with this.

TBH to some, the things I am trying to build into this core can seem arbitrary or weird or 'not commodore compliant' but some of the stuff, like the 85816, there IS software for it. You can run this software on VICE, or if you have a SuperCPU expansion, but by darn, MiSTer users should be able to run it too.

[Caldor]

Yeah, SD2IEC has been supported by GEOS for a while. There are other use cases as well. Mainly that quite a lot of games have gotten really good SD2IEC ports by the community, and I would argue they seem to be some of the best versions. Often you can even save directly to the SD2IEC. In some other thread someone asked why bother with SD2IEC support in the MiSTer if it was only CommodoreOS that supported it, but there is a lot of support for SD2IEC, if you look into it. Its just that many have not had much reason to look into it.

When custom cartridge ports are made of games, it usually starts out as a SD2IEC game.

[Grumpy-Old-Gamer]

From a 10,000-foot overview, it seems like the SD2IEC is doing the same thing that the Mister is already doing, just with a different interface. If someone implements it, it might be nice to have a toggle to either send the commands out the SNAC port, or else redirect them to the existing drive code. That way, you can either provide a real SD2IEC or a virtual one.

Depending on how that's implemented, however, the complexity of trying to support two drive interfaces at once could be gnarly. I bet there are a ton of corner cases lurking. Like, when you mount a drive, do you expose it both the normal way and as IEC? Do you keep IEC separate? If so, preventing the IEC code from connecting to the same disk the regular code is using would probably be important. And that's just the surface; it seems like there's a lot that could go horribly wrong. External IEC only is likely to be a lot simpler.

The issue with the SD2IEC it's not a true 1541 drive emulator so doesn't handle fast loader's or protected disks
Hopefully with some work the 1541 emulation on MiSTer can be as good as the other FPGA C64 devices, there is early G64 support added already

Only early G64 support? Its not full G64 support?

Nope so images of original disks wont work but its not a massive issue really. The C64 core has come on nicely considering its 20 year old origins tbf

[Juri]

Is this project dead?

[FPGA64]

Its just resting pining for the Fjords