Commodore 128 for the MiSTer?

[mapf]

I should have mentioned that I tested PAL only.

[eriks5]

VDC output works now on a CRT TV. Infocom's text adventures look sharp in NTSC. Running a PAL demo I can see pixels shaking very slightly, but I don't know how image looked on real hardware to judge it properly. I heard that VDC's output spec could be stretched pretty wide by programmers.
Thanks for the update.

The horizontal jitter is due to the asynchronous clocking of the VDC, to make it's timing behave like the real thing. It's the same issue that causes some video filters (most notably the gamma ones) to be noisy. I might find some solution for this, but I don't know one right now.

[ron]

Comparing C128 core and C128 real hardware, I was testing the core and what called my attention was that the Vic II-e does not work correctly when using the $d030 trick and the CPU at 2 MHz.

rfo_into01.png (7.81 KiB) Viewed 12908 times

And should look like:

into1sfo_01.png (439.34 KiB) Viewed 12908 times

Here's another screen, doesn't look ok.

rfo_demoscr02.png (220.92 KiB) Viewed 12908 times

Here's the real screen:

2ndokrfo.png (509.65 KiB) Viewed 12908 times

The Demo is here: https://www.pouet.net/prod.php?which=9339

The Vic works at 1 MHz, some out of sync or failure in the timers, perhaps it is not correctly implemented. You have to see what is happening there because otherwise the core will not be working correctly.

Other than that, it looks like a great job.

[eriks5]

Comparing C128 core and C128 real hardware, I was testing the core and what called my attention was that the Vic II-e does not work correctly when using the $d030 trick and the CPU at 2 MHz.

Yes I know. This is even listed as a todo in the README

[BlueIn2Red]

Interestingly the 80 column mode doesn't sync still on my CRT TV (a PAL Sony Trinitron). I definitely have the latest core from the 25th.

[BlueIn2Red]

Interestingly the 80 column mode doesn't sync still on my CRT TV (a PAL Sony Trinitron). I definitely have the latest core from the 25th.

Apologies, it works fine - I'd forgotten you need to reset to get it to take full effect.

[mike351]

Hi all.
Not sure if I have misses something in the docs or forum posts, however I'm unable to get an 80 column display on my Samtron 55E vga monitor. After selecting 80 column mode, the display goes dark and the power led just flashes on and off as though it has lost sync. I just downloaded the C128 core yesterday using the Update_All script, and it reports version v230325.
Mister version reports itself as v230223
I'm in PAL land, and using a Heber Mister Multi System. 40 Column mode works, and other cores seem to be ok with the vga monitor.
80 column does display on a HDMI connected display.

[burntweasel]

Just ran update_all and it seems 80 column mode is not working for me now, over HDMI. MiSTer v230423, C128 v230325.

When I switch to 80 column mode, the screen is corrupted. Anyone else having the same problem?

[deadlocked]

Just ran update_all and it seems 80 column mode is not working for me now, over HDMI. MiSTer v230423, C128 v230325.

When I switch to 80 column mode, the screen is corrupted. Anyone else having the same problem?

Hi burntweasel. I am on the latest main MiSTer (20230423), the latest C128 core (20230325) and I updated my kernel today. I am not seeing this issue, my 80 column screen looks fine and I can run VDC demos without screen corruption.

You may want to check that you are on the latest on all of the above (especialy the kernel, that you did not mention having upgraded) and, if you are running a custom C128 kernal, try switching to the stock one? Also check your SD card for errors, about a year ago I was having weird issues with some cores and it turned out that my sd card was corrupted, so I reformatted, recreated it using the sd card installer it and restored it from a backup and all worked well afterwards.

Also try re-downloading the main mister file and your c128 file, in case they got corrupted during transfer.

[burntweasel]

Thanks for the advice deadlocked, I tried re-copying both the main MiSTer file and the C128 core, and I checked the SD card for errors & found none. I also tried previous versions of both the MiSTer file and the C128 core.

I found that:

MiSTer 20230423 + C128 20230325 => Corrupt 80 column display
MiSTer 20230223 + C128 20230325 => Corrupt 80 column display
MiSTer 20230423 + C128 20230223 => 80 column display works fine
MiSTer 20230223 + C128 20230223 => 80 column display works fine

My conclusion is that is must be a problem with the latest 20230325 version of the C128 core, at least for me.

I attached a quick video of what's happening.

[deadlocked]

Thanks for the advice deadlocked, I tried re-copying both the main MiSTer file and the C128 core, and I checked the SD card for errors & found none. I also tried previous versions of both the MiSTer file and the C128 core.

I found that:

MiSTer 20230423 + C128 20230325 => Corrupt 80 column display
MiSTer 20230223 + C128 20230325 => Corrupt 80 column display
MiSTer 20230423 + C128 20230223 => 80 column display works fine
MiSTer 20230223 + C128 20230223 => 80 column display works fine

My conclusion is that is must be a problem with the latest 20230325 version of the C128 core, at least for me.

I attached a quick video of what's happening.

Oh that makes a lot of sense. I have seen a similar screen with some video settings in the newer core versions, but NOT in the older core versions. Press F12 to into the core settings > Audio & Video > Check that:

Vertical Crop : No
Scale: Normal

If that does not fix the issue, go to Video Processing (on the second menu page) and disable all video filters.

Some video filters cause the VDC screen to become corrupted. I think erik5 said some video filters do not play well with the VDC non-standard timings.

I hope this helps.

[burntweasel]

Thanks deadlocked, changing those settings fixed the problem. It’s unfortunate though that it makes the screen significantly smaller on the HDMI output.

For now I will just use the old version of the core, and keep an eye on newer versions to see if this improves.

Anyway I am super happy to have a C128 as I did as a kid! And I appreciate your help!

[deadlocked]

Thanks deadlocked, changing those settings fixed the problem. It’s unfortunate though that it makes the screen significantly smaller on the HDMI output.

For now I will just use the old version of the core, and keep an eye on newer versions to see if this improves.

Anyway I am super happy to have a C128 as I did as a kid! And I appreciate your help!

I feel the same way. The core used to work for me with Vertical crop = yes and Scale = full screen on older versions of the core, but now the screen is badly centered and the borders are huge, so I waste about 40% of my screen real estate. I hope in the future the resolution is at least back to what it used to be on older versions of the core, it worked best then.

[Alynna]

Comparing C128 core and C128 real hardware, I was testing the core and what called my attention was that the Vic II-e does not work correctly when using the $d030 trick and the CPU at 2 MHz.

Yes I know. This is even listed as a todo in the README

Is it permissible for me to contribute to this core yet?

I have been waiting for things to stabilize before continuing on SuperCPU128DX.

I would like to work from the latest core code you are releasing and just try to merge the latest into SuperCPU128DX,

But there is also some stuff I want to port back to the main core, like my 8mb MMU.

Would this be OK?

[Alynna]

This is what I would like to submit:

Code: Select all

The 8732 24/32 bit MMU.  As currently implemented.  Would like to backport this.
When used in a C128, it is entirely register compatible.  However some Registers
havbe been given additional functions.  

Because of certain mappings, the default memory available currently is 8mb.
Once it is decided where the expansion memory should be mapped, it can span the entire
space of the SDRAM of the MiSTer, offering even more RAM.

Anything marked [SuperCPU128DX] is not intended to be backported to the C128 core.
Please ignore it, as it is primarily because the MMU on SuperCPU128DX implements them,
and they will be IFDEFed out in the backported component.

The following enhacements would be delivered to the C128 core:
* AT LEAST 8mb of pagable memory, usually in bank 2 and 3 of the MMU, but in theory
  a system can be created that banks page 0 and 1, allowing for some interesting
  multitasking tricks.
* Writable RAM at D200-D3FF, which then can be marked read only and treated as ROM.
* Once memory mappings are decided, it could be made possible to address REU memory
  directly in MMU pages 2 and 3, by mapping REU memory into banks of MMU memory.

This memory is entirely usable by BASIC v7 through the following procedure
	mmu=dec("d500")			:REM: We want the MMU
	bank 15					:REM: We want to be able to address it
	poke mmu+13,16			:REM: Select page 16 ($100000) for MMU bank 3
	bank 3					:REM: Select MMU bank 3
	poke 32768,128			:REM: You can read and write to all of memory here
							:REM: Here we are writing $80 to $108000
	x=peek(32768)			:REM: You'll get 128.

Since page 2 and 3 are not normally used, you can reassign them all you want.  Returning
to a default config can be done by using one of the preconfiguration registers, or doing this.
NOTE: this is the boot default

bank 15
poke mmu+12,2			:REM: Set MMU page 2 to memory page 2
poke mmu+13,3			:REM: Set MMU page 3 to memory page 3

After this, the C128 will simply look like a 256k C128.  To simulate a 128k C128 do this.

bank 15
poke mmu+12,0			:REM: Set MMU page 2 to memory page 0
poke mmu+13,1			:REM: Set MMU page 3 to memory page 1

NI = Not currently implemnented
$D5xx ------------- SuperCPU128DX 8732 "Ariel" 24/32 bit MMU ---------------------------
$D500	1	MMUCR1	Configuration register
				7-6 MMU bank mapped to CPU (0-3)
				5-4 ROM HI mapping (00=System; 01=IntRom; 10=ExtRom; 11=RAM)
				3-2 ROM MID mapping (00=System; 01=IntRom; 10=ExtRom; 11=RAM)
				1   ROM LOW mapping (0=System; 1=RAM)
				0   I/O at $D000 (1=Yes; 0=No)
$D501	1	PCRA		Preconfiguration register A as above (triggered at FF01)
$D502	1	PCRB		Preconfiguration register B as above (triggered at FF02)
$D503	1	PCRC		Preconfiguration register C as above (triggered at FF03)
$D504	1	PCRD		Preconfiguration register D as above (triggered at FF04)
$D505	1	MMUMCR	Mode configuration register
                    	7	40/80 key sense (1=80; 0=40)
                    	6	OS mode (0=C128; 1=C64)
                    	5	/EXROM sense
                    	4	/GAME sense
                    	3	FSDIR
                    	2-1	[C128]	Page $D2-D3 function (D200-D3FF)
									00,01=Stock config, mirrors of VIC
									10=RAM, 11=RAM (Write protected, ROM emulation)
							[SuperCPU128DX]
									00=Stock config, mirrors of VIC, 01=85816 CPU cache
									10=RAM, 11=RAM (Write protected, ROM emulation)
                    	0	Processor 
							[C128] (0=Z80; 1=8502)
							[SuperCPU128DX] (0=Boot State Machine / 1=85816/85832)
$D506	1	MMURCR	RAM configuration register
                    	7-6 VIC RAM Bank (0-3)
                    	5-4 [NI] MMU v1 ExRAM (0=Pages 0-3; 1=Pages 4-7; 2=Pages 8-11; 3=Pages 12-15) 
								 V1 may never be implemented.  Its kind of useless with V2.
                    	3-2 RAM share status (0=None; 1=Top; 2=Bottom; 3=Both)
                    	1-0 RAM share amount (0=1k; 1=4k; 2=8k; 3=16k)

[ In MMUv2 mode, these registers are 8 bit and can relocate ZP/SP to any page in the 16mb addressing space ]
$D507 1	MMUP0L	Zero page pointer low (nn = xxnn00-xxnnFF)	
$D508 1	MMUP0H	Zero page pointer high (nn = nnxx00-nnxxFF)	
$D509 1	MMUP1L	Stack page pointer low (nn = xxnn00-xxnnFF)
$D50A 1	MMUP1H	Stack page pointer high (nn = nnxx00-nnxxFF)
$D50B 1	MMUVER	MMU Bank and version #
                    	7-4 Banks nnnn = 2^(nnnn) banks (1=128k; 2=256k; 4=1MB; 8=16MB; 15=2GB)
                    	3-0 MMU Version (0=Stock; 1=ExRAM available (1mb); 2=Page2/3 16MB paging available; 3=Page2/3 2GB paging available)
						(The MMU version MAY become a writable register allowing for fallback modes and enablement of features, but writing
						 is not currently implemented.)
[ Registers only present when MMU reports as version 2 [D50B=x2]]						
$D50C 1	MMUPG0L	RAM bank LSB at MMUv2 bank 0 (256 banks * 64k = 16MB)
$D50D 1	MMUPG1L	RAM bank LSB at MMUv2 bank 1 (256 banks * 64k = 16MB)
$D50E 1	MMUPG2L	RAM bank LSB at MMUv2 bank 2 (256 banks * 64k = 16MB)
$D50F 1	MMUPG3L	RAM bank LSB at MMUv2 bank 3 (256 banks * 64k = 16MB)
[ Registers only present when MMU reports as version 3 [D50B=x3]]						
$D510 1	MMUPG0H	[NI] RAM bank MSB at MMUv3 bank 0 (32768 banks * 64k = 2GB)
$D511 1	MMUPG1H	[NI] RAM bank MSB at MMUv3 bank 1 (32768 banks * 64k = 2GB)
$D512 1	MMUPG2H	[NI] RAM bank MSB at MMUv3 bank 2 (32768 banks * 64k = 2GB)
$D513 1	MMUPG3H	[NI] RAM bank MSB at MMUv3 bank 3 (32768 banks * 64k = 2GB)

[Alynna]

Note that in SuperCPU128DX, the VDC RAM can be seen by the MMU, by an expansion register that tells the VDC where to find its 64K RAM in the 16mb available. This does what one would expect:

• The VDC can be page-flipped
• The VDC RAM can be POKEd into without having to go through D600/D601
  I would like to backport this functionality at some point.

[eriks5]

I would like to work from the latest core code you are releasing and just try to merge the latest into SuperCPU128DX,

The vic branch I'm currently working on to implement the $D030 tricks also introduces some major changes the sysCycle state machine, so maybe hold off on merging until that branch lands. No ETA for it. VIC part is now 99.9% working (RfO VIC part is almost pixel perfect), but currently Z80 and VDC are broken due to the changes in the state machine.

But there is also some stuff I want to port back to the main core, like my 8mb MMU.

Would this be OK?

As discussed before, anything that does not exist for the real hardware is not really an option for inclusion. I don't think there's much use for an 8Mb MMU. And moving the VDC memory to SDRAM would probably introduce lots of timing issues.

[Alynna]

alright, i'll keep watching your branch and stay on hold. The new syscycle state machine might the 65816 compatible part i'm working on, actually work right when included in the SuperCPU128DX.

[ron]

I would like to work from the latest core code you are releasing and just try to merge the latest into SuperCPU128DX,

The vic branch I'm currently working on to implement the $D030 tricks also introduces some major changes the sysCycle state machine, so maybe hold off on merging until that branch lands. No ETA for it. VIC part is now 99.9% working (RfO VIC part is almost pixel perfect), but currently Z80 and VDC are broken due to the changes in the state machine.

But there is also some stuff I want to port back to the main core, like my 8mb MMU.

Would this be OK?

As discussed before, anything that does not exist for the real hardware is not really an option for inclusion. I don't think there's much use for an 8Mb MMU. And moving the VDC memory to SDRAM would probably introduce lots of timing issues.

I have already seen ( git ) that you have fixed the $D030 trick, I have synthesized and IT WORKS !. Very nice !!!
Congratulations. 80 columns mode looks great. Much better and I guess fixing Z80 and disk drive, you've got it !!!

Thanks a lot.

[eriks5]

I have already seen ( git ) that you have fixed the $D030 trick, I have synthesized and IT WORKS !. Very nice !!!
Congratulations. 80 columns mode looks great. Much better and I guess fixing Z80 and disk drive, you've got it !!!

z80 is already fixed (but not pushed yet), but I found some other regressions with the VIC, for example sprite collision detection is off by 3 pixels, so timing is still a bit off. It's a lot of fiddling with the timings, and since each build takes more than 15 minutes, debugging and testing is slow.

I'm not aware of issues with the disk drive, care to elaborate?

[ron]

z80 is already fixed (but not pushed yet), but I found some other regressions with the VIC, for example sprite collision detection is off by 3 pixels, so timing is still a bit off. It's a lot of fiddling with the timings, and since each build takes more than 15 minutes, debugging and testing is slow.

I'm not aware of issues with the disk drive, care to elaborate?

Let me check it again, but CP/M did not finish loading due to disk error. I need to replay it. It's only with Z80 mode.

[cathrynmataga]

I'm using this CPM here. https://github.com/csoren/c128cpm/blob/ ... pm+128.d71 -- this loads into CPM fine. Though I have zero software for this mode. Is there anything to use CPM for? Is there Zork for CPM? Is there vi for CPM?

I had C64 back in the day, but never had C128. Interesting to see what it was like. Just trying out GEOS128. This would have been a successful computer if it came out just a little earlier, I think.

[cathrynmataga]

And I did get dialogue term running, like in that video. I was unable to get DesTerm working. Maybe a config issue, but I couldn't figure it out.

[rhester72]

DesTerm is picky about version (the most recent doesn't seem to start at all because it's a catch-22 of can't-change-the-driver-until-it-boots design), the older works well but handles drive mappings and REU very oddly.

[cathrynmataga]

Oh, thanks, you're right. For me DesTerm 2.1 works, DesTerm 3.0 does not. For future googlers, what works for me is "Expansion:RS232, RS232 mode:VIC-1011, RS232 Connection: Internal" DesTerm 2.1 seems to work at 9600, though I haven't really stressed it out.

[eriks5]

I'm using this CPM here. https://github.com/csoren/c128cpm/blob/ ... pm+128.d71 -- this loads into CPM fine. Though I have zero software for this mode. Is there anything to use CPM for? Is there Zork for CPM? Is there vi for CPM?

Zimmers has CP/M software for the C128: https://www.zimmers.net/anonftp/pub/cpm/sys/c128/

The InfocomCollection.zip in the games section has Zork iirc

[ron]

Five minutes ago I have synthesized the new changes from git and I have to say that CP/M is now booting and is fully operational again.
I really like the state it is in right now and I congratulate you because you have done a great job. Every day it is closer.

Works Great ! Cheers eriks5

[deadlocked]

I also compiled the source code today and I have been running a few demos in c128 mode and wow, it's like day and night. I can now set the scale to full screen and vertical crop to yes so the screen real estate is now much better utilized and screen centering is dramatically improved. Thanks erik5 for the improvements!

Also, for those who compile the source code yourselves or get the next release (when it comes out) with all these changes included, please be aware that most demos will glitch or crash if you change the 8502 turbo mode because... instruction set timings. 8502 turbo mode is best used to speed up BASIC programs, but many games and demos will not like an overclocked 8502 CPU. Finally, demos that display graphics over the border area will be cut off at the top and bottom if you set vertical crop to yes. This is normal behavior and not a bug. I personally prefer to run with vertical crop on to minimize the border area most of the time and only switch it off for specific game(s) or demos that display graphics over the border.

[eriks5]

Five minutes ago I have synthesized the new changes from git and I have to say that CP/M is now booting and is fully operational again.

I also compiled the source code today and I have been running a few demos in c128 mode and wow, it's like day and night.

Nice. Thanks guys. Was planning on releasing yesterday but found a last-minute bug. A weird one even. Could you guys check GEOS 128 in 80-col mode? For me, the video output is sometimes unstable. Weird thing is, when I recompile with signaltap, it's stable

So there might be some issue in the synthesis where the result depends on randomness during build time.

Also, for those who compile the source code yourselves or get the next release (when it comes out) with all these changes included, please be aware that most demos will glitch or crash if you change the 8502 turbo mode because... instruction set timings. 8502 turbo mode is best used to speed up BASIC programs, but many games and demos will not like an overclocked 8502 CPU. Finally, demos that display graphics over the border area will be cut off at the top and bottom if you set vertical crop to yes. This is normal behavior and not a bug. I personally prefer to run with vertical crop on to minimize the border area most of the time and only switch it off for specific game(s) or demos that display graphics over the border.

Good notes. I'll add something like this to the README

[ron]

I look forward to you correcting that last minute bug and publishing soon, you are very close to getting it completely right