Try putting some NOPs between the acquisition of ROM_LOCK and assertion of PSRAM_SELECT (line 5465). Otherwise, really no idea how the Z80 could have read issues when the 68000 isn't.
@evanh said:
Oops, I read that as video distortions.
The video was good (and still is). The audio is not suitable for hearing. I switched it to VGA2x but I didn't notice any important changes. The video now signals 640x480x60 Hz,
@Wuerfel_21 said:
Try putting some NOPs between the acquisition of ROM_LOCK and assertion of PSRAM_SELECT (line 5465). Otherwise, really no idea how the Z80 could have read issues when the 68000 isn't.
Other thing to try maybe is go to line 2745 and add P_SYNC_IO to the clock pins mode (and then fiddle with PSRAM_DELAY)
Otherwise, really no idea how the Z80 could have read issues when the 68000 isn't.
I didn't yet try to apply these suggestions, but the waveform shape suggests that there may be also endianness/nibbles order problem. After I will finish the paperwork I have to do now, I will look at this code once again
Otherwise, really no idea how the Z80 could have read issues when the 68000 isn't.
I didn't yet try to apply these suggestions, but the waveform shape suggests that there may be also endianness/nibbles order problem. After I will finish the paperwork I have to do now, I will look at this code once again
Certainly not, it works fine here. Must be a hardware/timing problem.
This is a thin border. Add 5 and it doesn't work at all. PSRAM_WAIT=11 doesn't work at all too. It's good that it works. This 4-bit stuff is cheapest and simplest RAM solution for a P2 as it can be, a good amount of working external RAM for $3 - a chip, a breakout board, a 12-pin connector and some PLA for the case.
@pik33 said:
This is a thin border. Add 5 and it doesn't work at all. PSRAM_WAIT=11 doesn't work at all too. It's good that it works. This 4-bit stuff is cheapest and simplest RAM solution for a P2 as it can be, a good amount of working external RAM for $3 - a chip, a breakout board, a 12-pin connector and some PLA for the case.
Yeah. The data is on the bus for two cycles, so there's exactly one delay setting that samples it on the right cycle (= closest to the center of the eye pattern coming down the bus).
I am at home now, with the second Eval+PSRAM set - this is slightly (works up to 350 MHz instead of 340) better PSRAM, but the delay add value has still to be 4. I got some more "roms", some of them with .smd" extension - they don't work here (at least the one I tried).
I don't know this Megadrive console at all. In 1994 I was already a PC user... after an Atari 8bit and Atari ST.
@pik33 said:
I am at home now, with the second Eval+PSRAM set - this is slightly (works up to 350 MHz instead of 340) better PSRAM, but the delay add value has still to be 4. I got some more "roms", some of them with .smd" extension - they don't work here (at least the one I tried).
SMD format files are from an old dumper device that copied cartridges onto floppies. It's got all the bytes scrambled around... Will be supported when I add the ability to load from SD card, but is unsuitable for directly loading into memory... maybe I can also adjust the loader script to handle in the meantime.
I don't know this Megadrive console at all. In 1994 I was already a PC user... after an Atari 8bit and Atari ST.
Wow, it really did come out in 1994 in Poland. That's 6 years late (compared to 1988 japanese launch), lol. Really passed eastern europe by, I guess.
I am thinking about a SD loader right now - I have already learned how to use the filesystem while writing the player.
But the first thing I want to do is to connect my RPi keyboard interface, the PC keyboard is way too big.
In Poland home computing started with the Spectrum, and then 8bit Ataris. A8 was my first computer in 1986. 8-bit Atari scene is still strong here ( https://sillyventure.eu/en/ )
Then, after 1989, teenagers switched to Amigas. I was no more teenager then, I graduated in 1989 and then I had to have a "real computer" to work, so I had to sell my Atari ST and bought a tin can called PC AT.
@pik33 said:
I am thinking about a SD loader right now - I have already learned how to use the filesystem while writing the player.
In theory it's easy, I just avoided it until now to make debugging easier. The real pickle is save memory, since that has to be written back to storage at some point, which will tie up the Spin cog for a bit. So I'll have to move control mapping into the USB code itself (which will also be lower latency in the end).
So, input handling is now moved entirely to the USB driver.
The interface for inputs is pretty simple. There's just two words at $40 that the button states need to be written.
New preview for the SPCcog (will get own thread when done).
Now without the crashes and less annoying clicks.
Still doesn't really work with squaresoft game soundtracks. Love myself some inscrutable CPU core bugs.
@Wuerfel_21 said:
I'm procrastinating messing with the memory stuff, aren't I?
Maybe you are. Do you have a free COG you can dynamically load my PSRAM or HyperRAM driver into at this time (just for writing the ROM to external RAM from SD), so you don't have to expend more effort to write another set of drivers that can write to all the different memory types?
@Wuerfel_21 said:
I'm procrastinating messing with the memory stuff, aren't I?
Maybe you are. Do you have a free COG you can dynamically load my PSRAM or HyperRAM driver into at this time (just for writing the ROM to external RAM from SD), so you don't have to expend more effort to write another set of drivers that can write to all the different memory types?
Now that you say it.. yes, I could likely just do that.
It would probably be the fastest way to make progress on it. You could potentially just use the driver's raw PASM2 component and just pass its HW setup variables correctly at COG startup time if memory is tight. The outer SPIN2 API can be always be removed/reduced to free space. Then you copy the memory, kill the driver COG once copied, and start your own emulator program.
So, uhh, memory amiright.
@rogloh
Uhm, is this right? It seems to start up correctly, but all the data gets garbled (I'm trying with PSRAM4 right now).
Comments
I managed to run the emulator!
I tried Sonic3 - the video seems to be OK, audio works, but has (strange) distortions.
Can I get a recording of that? Note that the sample playback in that game just is distorted (bad sound code)
Ada has some weird monitor. Change it from MODE_VGA3X default to MODE_VGA2X.
The audio sample:
https://drive.google.com/file/d/1Hi8pVgoh1iQpl9dS87PWYnciYsM1_83P/view?usp=sharing
Oh, yeah. That sounds like the Z80 has issues reading from PSRAM
Oops, I read that as video distortions.
Try putting some NOPs between the acquisition of ROM_LOCK and assertion of PSRAM_SELECT (line 5465). Otherwise, really no idea how the Z80 could have read issues when the 68000 isn't.
The video was good (and still is). The audio is not suitable for hearing. I switched it to VGA2x but I didn't notice any important changes. The video now signals 640x480x60 Hz,
Other thing to try maybe is go to line 2745 and add
P_SYNC_IOto the clock pins mode (and then fiddle with PSRAM_DELAY)I didn't yet try to apply these suggestions, but the waveform shape suggests that there may be also endianness/nibbles order problem. After I will finish the paperwork I have to do now, I will look at this code once again
Certainly not, it works fine here. Must be a hardware/timing problem.
This helped:
At line 51
PSRAM_DELAY = PSRAM_WAIT*2+4instead of 3
Good to hear that only delay needs tweaking
This is a thin border. Add 5 and it doesn't work at all. PSRAM_WAIT=11 doesn't work at all too. It's good that it works. This 4-bit stuff is cheapest and simplest RAM solution for a P2 as it can be, a good amount of working external RAM for $3 - a chip, a breakout board, a 12-pin connector and some PLA for the case.
Yeah. The data is on the bus for two cycles, so there's exactly one delay setting that samples it on the right cycle (= closest to the center of the eye pattern coming down the bus).
I am at home now, with the second Eval+PSRAM set - this is slightly (works up to 350 MHz instead of 340) better PSRAM, but the delay add value has still to be 4. I got some more "roms", some of them with .smd" extension - they don't work here (at least the one I tried).
I don't know this Megadrive console at all. In 1994 I was already a PC user... after an Atari 8bit and Atari ST.
SMD format files are from an old dumper device that copied cartridges onto floppies. It's got all the bytes scrambled around... Will be supported when I add the ability to load from SD card, but is unsuitable for directly loading into memory... maybe I can also adjust the loader script to handle in the meantime.
Wow, it really did come out in 1994 in Poland. That's 6 years late (compared to 1988 japanese launch), lol. Really passed eastern europe by, I guess.
I am thinking about a SD loader right now - I have already learned how to use the filesystem while writing the player.
But the first thing I want to do is to connect my RPi keyboard interface, the PC keyboard is way too big.
In Poland home computing started with the Spectrum, and then 8bit Ataris. A8 was my first computer in 1986. 8-bit Atari scene is still strong here ( https://sillyventure.eu/en/ )
Then, after 1989, teenagers switched to Amigas. I was no more teenager then, I graduated in 1989 and then I had to have a "real computer" to work, so I had to sell my Atari ST and bought a tin can called PC AT.
In theory it's easy, I just avoided it until now to make debugging easier. The real pickle is save memory, since that has to be written back to storage at some point, which will tie up the Spin cog for a bit. So I'll have to move control mapping into the USB code itself (which will also be lower latency in the end).
So, input handling is now moved entirely to the USB driver.
The interface for inputs is pretty simple. There's just two words at $40 that the button states need to be written.
New preview for the SPCcog (will get own thread when done).
Now without the crashes and less annoying clicks.
Still doesn't really work with squaresoft game soundtracks. Love myself some inscrutable CPU core bugs.
Working on megayume menu system.
Works:
accessing flexspin's cog-less filesystem from Spin (despite the documentation claiming that it only works in C and BASIC)
setting up the virtual VDP for menu usage
rendering ShiftJIS text (have to dynamically render to a buffer so the full (well, it's JIS level 1 only...) font can stay 1bpp)
still booting into a game afterwards
Well, got a vaguely functioning filechooser put together, now for the hard part, actually getting data into memory
While I was at it, I figured out how those silly .SMD rom files work.
Brought to you by this funny bit of code:
if smdrom i := $3FFF org .lp mov j,i .adj shr j,#1 wc bitnc j,#13 cmp i,j wc if_b jmp #.adj add i,dest add j,dest rdbyte tmp1,i rdbyte tmp2,j wrbyte tmp2,i wrbyte tmp1,j sub i,dest djnf i,#.lp endLoading bar... isn't actually loading anywhere, BUT LOOK the bar looks like a lot of tiny ROMs, isn't that cute?
Also, ROM info display, yay.
...
...
I'm procrastinating messing with the memory stuff, aren't I?
Maybe you are. Do you have a free COG you can dynamically load my PSRAM or HyperRAM driver into at this time (just for writing the ROM to external RAM from SD), so you don't have to expend more effort to write another set of drivers that can write to all the different memory types?
Now that you say it.. yes, I could likely just do that.
It would probably be the fastest way to make progress on it. You could potentially just use the driver's raw PASM2 component and just pass its HW setup variables correctly at COG startup time if memory is tight. The outer SPIN2 API can be always be removed/reduced to free space. Then you copy the memory, kill the driver COG once copied, and start your own emulator program.
So, uhh, memory amiright.
@rogloh
Uhm, is this right? It seems to start up correctly, but all the data gets garbled (I'm trying with PSRAM4 right now).
Hmm, if I increment the delay value by one, it seems to work. Weird, but ok I'll take it.
EDIT: Wait no it still doesn't
EDIT 2: Wait no it actually does work I just didn't offset the addresses right
EDIT 3: Still doesn't seem right, only boots to red screen of death (SEGA's init code detects checksum error)