You can write a tiny stub program in either the boot or volume sector(s) of the SD card. This can remain there permanently.
SD Boot Code
Provided a pull-up is sensed on P61=#CS (provided by the SD Card itself) and the other conditions are met, then the Booter code will pass control to the SD Boot Code. The SD code performs the following steps…
• Initialise the SD Card (in SPI mode). This is often referred to as “Mounting” the card.
• If successful, read the MBR Sector $0000_0000 (512 bytes) into HUB RAM starting at HUB $00000.
• Check if the 4 signature bytes at MBR offset $17C (now in HUB) contain “Prop” ($706F7250). If valid, then the MBR sector now residing at HUB $00000-$001FF (128 longs) is copied into COG RAM $000 and then a JMP $020 is executed. This has the effect of COG #0 executing the code loaded from the MBR starting at byte offset $080. Note the whole 512 byte (128 longs) sector is loaded into COG, so while the code starts at $080 (COG $020), this code can use code below this address if that code is valid and executable. Note that certain parts of the MBR are required by FAT32, etc. Any P2 code written into the MBR must maintain any required fields that the SD card format requires.
• If the MBR does not contain “Prop” at $17C, then this location is checked for the signature “ProP” ($506F7250). If this is found, then $174 (4 bytes) is used as the raw SD Sector to start loading from, and $178 (4 bytes) is used as the length (in bytes). The program then reads code from the card beginning at the start sector for the length into HUB RAM beginning at HUB $00000. Upon completion of the load, 496 longs from HUB $00000 are copied into COG $0 and a JMP #$000 is executed to run the loaded code in COG.
• If the MBR does not contain either signature, then the MBR is validated as follows:
o $1BE[16] is the Ptn0 Table
o $1BE+0[1] AND $7F must equal $00
o $1BE+4[1] must be $0C or $0B
o $1BE+8[4] is used as the Vol_Begin sector
o $1BE+C[4] is used at the Ptn Size
o $1FE[2] must be $55AA
If these checks are met, then continue, else go back to Serial boot code.
• The VOL sector is now read into HUB $00000, and it is checked for the signature “Prop” or “ProP” at offset $17C. If either is found, then the operation will continue the same as described above for the signature found in the MBR sector.
• If the VOL does not contain either signature, then the VOL is validated as follows:
o $00B[2] must be 512
o $00D[1] is used at the clustershift
o $00E[1] used to calculate FAT begin
o $010[1] must be 2 (number of FAT tables)
o $020[4] used to calculate PTN size (not checked)
o $024[4] used to calculate DIR begin
o $030[2] used to calculate FSI begin
o $1FE[2] must be $55AA
If these checks are met, then continue, else go back to Serial boot code.
• The FSI sector is read and validated as follows:
o $000[4] must be $RRaA
o $1E4[4] must be $rrAa
o $1FE[2] must be $55AA
If these checks are met, then continue, else go back to Serial boot code.
• The FAT DIRectory is now searched for the file “_BOOT_P2.BIX”. If it is found, it is read into HUB $00000 for a maximum length of (512-16)*1024 which is 512-16KB such that it will not overwrite the top 16KB of HUB RAM. Then the first 496 longs will be copied into COG $000 and a JMP #$000 will execute.
WARNING: This file must be contiguous on the SD Card! This is not checked!!
• If the above file is not found, then the FAT DIRectory is searched for the file “_BOOT_P2.BIY”. If it is found, then it will be read and executed in the same process as the previous step.
• If neither file is found, the code returns to the Serial boot code.
Here's why to run the 68000 on the raspberry pi for games that really could use the performance: Emu68(bare metal emulation, currently of just 68000, ram and hard drive) on a $15 Raspberry Pi Zero 2W is 1135times as fast as a 7MHz Amiga! The Musashi emulator runs on top of Raspberry Pi OS and runs the emulator at about 32x as fast (on the $15 Zero2W) as a 7MHz 68000, and also give you RAM, HD, Network, and RetargetableGraphics (hdmi out), and I think even USB input device while it uses the Amiga hardware for floppy, keyboard, mouse. Chip RAM, Agnus, Paula, Gary, Denise, and the CIA's. I'm thinking that Agnus, Paula, Gary, Denise, and the CIA's can all be emulated by the P2.
Zero 2W is the same chip as 3, while the hardware configuration is like 3A+. It is cheap, but now Pis are hard to find.
I have Zero 2, so I want to replace an old Zero with it as a P2 board companion. However, there is a bug in Ultibo which prevents it to properly recognize Raspberry Pi official keyboard with a Pi Zero 2. Reported, I am waiting for the solution, then I will replace old Zero with this.
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc.
Version 5.9.12-beta-HEAD-v5.9.11-2-g85b1a2e2 Compiled on: Jun 3 2022
neoyume_upper.spin2
|-NeoVGA.spin2
|-NeoVGA.spin2
|-libc.a
|-fsadapter.c
|-psram16drv.spin2
neoyume_upper.spin2:361: error: unknown identifier strcasecmp in class libc_a
neoyume_upper.spin2:268: error: unknown identifier strerror in class libc_a
neoyume_upper.spin2:276: error: unknown identifier strerror in class libc_a
neoyume_upper.spin2:268: error: unknown identifier strerror in class libc_a
neoyume_upper.spin2:268: error: unknown identifier strerror in class libc_a
neoyume_upper.spin2:276: error: unknown identifier strerror in class libc_a
neoyume_upper.spin2:276: error: unknown identifier strerror in class libc_a
neoyume_upper.spin2:352: error: unknown identifier strerror in class libc_a
neoyume_upper.spin2:361: error: unknown identifier strcasecmp in class libc_a
neoyume_upper.spin2:352: error: unknown identifier strerror in class libc_a
neoyume_upper.spin2:352: error: unknown identifier strerror in class libc_a
neoyume_upper.spin2:361: error: unknown identifier strcasecmp in class libc_a
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc.
Version 5.9.12-beta-HEAD-v5.9.11-2-g85b1a2e2 Compiled on: Jun 3 2022
neoyume_input.spin2
|-NeoVGA.spin2
|-1CogKbM_neoyume.spin2
neoyume_input.p2asm
Done.
Program size is 9160 bytes
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc.
Version 5.9.12-beta-HEAD-v5.9.11-2-g85b1a2e2 Compiled on: Jun 3 2022
neoyume_lower.spin2
|-NeoVGA.spin2
neoyume_lower.spin2:7758: error: file neoyume_upper.binary: No such file or directory
I do, but as of a few hours ago, my changes are on master. 85b1a2e is from may 22nd. You need to build the spin2cpp repo on its own to get a proper freshie, the Flexprop repo only updates its submodule pointer on releases.
@pik33 said:
Is there anybody with P2-EC32 rev B who can check if it works on this board?
Yeah, please. I'm still massively confused by how it is possible to have the game running fine but with garbled graphics. And I think you said there's no sound?
Can you post the .p2asm and .lst files generated during build? Could be some sort of flexspin bug that's sensitive to platform (you're on Linux, right?)
@pik33 said:
Compiled, still the same mess on the screen with Metal Slug as before. Is there anybody with P2-EC32 rev B who can check if it works on this board?
I'll try after the weekend if no-one else gets there first
--> If the Metal Slug file isn't included at the GitHub download, could someone PM me a link where to download it ?
You undid the if_c thing, right? You say zero does nothing? Well, that wasn't it then (the idea was that maybe they made some revision to the PSRAM and it now no longer ignores the address MSBs, like HyperRAM).
The code for sound and graphics access is almost the same (and if anything, the sound is the rickety one), they are literally the same. I do not understand. My braaaaaaaaaiiiiinnnn.
I guess you could go to 2990/2991 in neoyume_lower and swap them (so WRFAST is after WAITXMT). I have no idea how that could affect anything, but its the only appreciable difference between these code path. I am at utter loss.
I am starting to blame the neo-epo.bin - there was discussion about it somewhere else (also garbled graphics) but I cannot find anything working - any "neo-geo bios" I found, gives me "backup ram error" address 00D000000 write 5555 read 0000. So I need to find the proper one.
The PSRAM can be in 2 flavors, where one can cross the 1k boundary while burst, the other can not. Rogloh's driver however never crosses the boundary.
The BIOS can't cause graphics corruption in any sensible way. You already have the correct, because it works at all.
And yes, only AES BIOSes (neo-epo.bin or neo-po.bin) will work, because the emulated system is an AES and thus doesn't pass the self-test of an MVS BIOS.
(for clarity: AES is the NeoGeo home console, MVS is the NeoGeo arcade machine)
The 1K boundary thing is handled: The graphics and sound reads are inherently aligned blocks and thus can never cross a boundary. The 68k reads can cross boundaries, but this is handled appropriately (and the 68k evidently is running just fine.)
Since there are two differing pcb revisions out there, another "eventual" question arises: Are there any chances these APMemory chips part #s or lot #s to differ among the two P2-EC32MB Revs?
IDK if they come with epoxy-markings, or laser-embossings; perhaps a good close-up image of these specific pcb-areas can "enlighten" all of it, someway...
@rogloh said:
To rule out build environment differences, Wuerfel_21 you could build and provide a top level P2 binary for pik33 to run. One that works fine for you.
I've made one a while ago, but it kinda got lost I think. Anyways, I compared pik's LST file to mine and there weren't any appreciable differences. Anyways, shouldn't you of all people have a monitor and some PSRAM around to try it at home? Give it a go!
@Yanomani said:
Since there are two differing pcb revisions out there, another "eventual" question arises: Are there any chances these APMemory chips part #s or lot #s to differ among the two P2-EC32MB Revs?
IDK if they come with epoxy-markings, or laser-embossings; perhaps a good close-up image of these specific pcb-areas can "enlighten" all of it, someway...
Here. My EC32MB is one of the very first ones.
But as said, it's not a general issue with the PSRAM access (program runs and sound is fine), which is why I'm so totally stabbing in the dark.
Another idea is that the reads are working fine but the writes setting up sprite data are putting this data into the wrong address for whatever reason.
@Wuerfel_21 said:
I've made one a while ago, but it kinda got lost I think. Anyways, I compared pik's LST file to mine and there weren't any appreciable differences. Anyways, shouldn't you of all people have a monitor and some PSRAM around to try it at home? Give it a go!
Away from my setup right now and don't have the needed files.
@rogloh said:
Another idea is that the reads are working fine but the writes setting up sprite data are putting this data into the wrong address for whatever reason.
That's not it, I think. Look at the first video pik posted (post #583). It doesn't look like it's getting wrong data from the right address, it just looks like it's reading nonsense (see the Metal Slug logo. That should just be a big static picture but it's just glitching about)
The nonsense might just be uninitialized data perhaps, if you don't clear out all PSRAM memory first (do you?). The glitching is weird though, like a timing problem almost, unless the game is just alternating sprites at those positions (maybe for animation effects). I wonder if there is anything else interfering with those pins...
I took that photo way back when I first got it, so no time spent.
@rogloh said:
The nonsense might just be uninitialized data perhaps, if you don't clear out all PSRAM memory first (do you?). The glitching is weird though, like a timing problem almost, unless the game is just alternating sprites are those positions (maybe for animation effects). I wonder if there is anything else interfering with those pins...,
I think it may be related to other bus activity. Notice how the pattern is static on the NeoGeo logo? The only other access at that point is the 68k program, which probably only runs for a few scanlines during VBlank And during the title sequence everything gets a bit glitchy, because there's ADPCM sound and more CPU activity. You can also kinda see it "ratchet" on the scrolling background during the gameplay demo when sprite slots shift over by one (backgrounds are built by placing a bunch of sprites next to eachother).
Comments
Oh yeah, also need the newest flexspin git builds
There is that.
Here is an idea...
You can write a tiny stub program in either the boot or volume sector(s) of the SD card. This can remain there permanently.
see the ROM listing and docs here
ROM Code Listing (Rev 1 & 2)
https://forums.parallax.com/discussion/comment/1480216/#Comment_1480216
SD Boot Code (Rev 2)
https://forums.parallax.com/discussion/170637/p2-sd-boot-code-rev-2-silicon
Monitor/Debugger (Rev2)
https://forums.parallax.com/discussion/170638/p2-rom-monitor-debugger-rev-1-rev-2-silicon
Here's why to run the 68000 on the raspberry pi for games that really could use the performance:
Emu68(bare metal emulation, currently of just 68000, ram and hard drive) on a $15 Raspberry Pi Zero 2W is 1135times as fast as a 7MHz Amiga! The Musashi emulator runs on top of Raspberry Pi OS and runs the emulator at about 32x as fast (on the $15 Zero2W) as a 7MHz 68000, and also give you RAM, HD, Network, and RetargetableGraphics (hdmi out), and I think even USB input device while it uses the Amiga hardware for floppy, keyboard, mouse. Chip RAM, Agnus, Paula, Gary, Denise, and the CIA's. I'm thinking that Agnus, Paula, Gary, Denise, and the CIA's can all be emulated by the P2.
Zero 2W is the same chip as 3, while the hardware configuration is like 3A+. It is cheap, but now Pis are hard to find.
I have Zero 2, so I want to replace an old Zero with it as a P2 board companion. However, there is a bug in Ultibo which prevents it to properly recognize Raspberry Pi official keyboard with a Pi Zero 2. Reported, I am waiting for the solution, then I will replace old Zero with this.
Well, we got github now: https://github.com/IRQsome/NeoYume
Also made the menu a bit more fancy and added a few more games to the database.
A fresh flexprop and a github source
Do you use a custom libc file?
I do, but as of a few hours ago, my changes are on master.
85b1a2eis from may 22nd. You need to build the spin2cpp repo on its own to get a proper freshie, the Flexprop repo only updates its submodule pointer on releases.Compiled, still the same mess on the screen with Metal Slug as before. Is there anybody with P2-EC32 rev B who can check if it works on this board?
Yeah, please. I'm still massively confused by how it is possible to have the game running fine but with garbled graphics. And I think you said there's no sound?
Can you post the .p2asm and .lst files generated during build? Could be some sort of flexspin bug that's sensitive to platform (you're on Linux, right?)
I'll try after the weekend if no-one else gets there first
--> If the Metal Slug file isn't included at the GitHub download, could someone PM me a link where to download it ?
Now there is sound playing - there was no sound in the first version I compiled. (0.03 or something like this)
What I can find in the directory after compilation are these 3 files.
Hmm, that seems to match mine (save for pin numbers) if I set DIRECT_BOOT (you did that, right?)
So I guess it really is a bug of some kind.
Sanity check: if you go to line 2974 (
if_c jmp #ma_lineloop) and remove theif_call sprites should turn into static striped blocks. Does that happen?This happened:
Yep, that is as expected.
So it is the graphics reads getting corrupted, but not the program and audio reads?
Still oh so very confused.
@pik33
Another hack to try: undo the previous thing, then go into the upper file and change line 194 from
long[$A4] := 31tolong[$A4] := 19EDIT: Wait no, it has to be 17 or 16
Either no effect or I cannot notice what changed. Tried 16,17,19 and even 0
I am now trying to get the game from another source. Or maybe try to get another bios?
You undid the if_c thing, right? You say zero does nothing? Well, that wasn't it then (the idea was that maybe they made some revision to the PSRAM and it now no longer ignores the address MSBs, like HyperRAM).
The code for sound and graphics access is almost the same (and if anything, the sound is the rickety one), they are literally the same. I do not understand. My braaaaaaaaaiiiiinnnn.
I guess you could go to 2990/2991 in neoyume_lower and swap them (so WRFAST is after WAITXMT). I have no idea how that could affect anything, but its the only appreciable difference between these code path. I am at utter loss.
I am starting to blame the neo-epo.bin - there was discussion about it somewhere else (also garbled graphics) but I cannot find anything working - any "neo-geo bios" I found, gives me "backup ram error" address 00D000000 write 5555 read 0000. So I need to find the proper one.
The PSRAM can be in 2 flavors, where one can cross the 1k boundary while burst, the other can not. Rogloh's driver however never crosses the boundary.
The BIOS can't cause graphics corruption in any sensible way. You already have the correct, because it works at all.
And yes, only AES BIOSes (neo-epo.bin or neo-po.bin) will work, because the emulated system is an AES and thus doesn't pass the self-test of an MVS BIOS.
(for clarity: AES is the NeoGeo home console, MVS is the NeoGeo arcade machine)
The 1K boundary thing is handled: The graphics and sound reads are inherently aligned blocks and thus can never cross a boundary. The 68k reads can cross boundaries, but this is handled appropriately (and the 68k evidently is running just fine.)
To rule out build environment differences, Wuerfel_21 you could build and provide a top level P2 binary for pik33 to run. One that works fine for you.
Since there are two differing pcb revisions out there, another "eventual" question arises: Are there any chances these APMemory chips part #s or lot #s to differ among the two P2-EC32MB Revs?
IDK if they come with epoxy-markings, or laser-embossings; perhaps a good close-up image of these specific pcb-areas can "enlighten" all of it, someway...
I've made one a while ago, but it kinda got lost I think. Anyways, I compared pik's LST file to mine and there weren't any appreciable differences. Anyways, shouldn't you of all people have a monitor and some PSRAM around to try it at home? Give it a go!
Here. My EC32MB is one of the very first ones.
But as said, it's not a general issue with the PSRAM access (program runs and sound is fine), which is why I'm so totally stabbing in the dark.
Another idea is that the reads are working fine but the writes setting up sprite data are putting this data into the wrong address for whatever reason.
Away from my setup right now and don't have the needed files.
That's not it, I think. Look at the first video pik posted (post #583). It doesn't look like it's getting wrong data from the right address, it just looks like it's reading nonsense (see the Metal Slug logo. That should just be a big static picture but it's just glitching about)
Thanks for sharing (and also for your time), Ada!
These USON8 packages are so tiny...
Hoping for pik33's ones to be identical twins of your's...
The nonsense might just be uninitialized data perhaps, if you don't clear out all PSRAM memory first (do you?). The glitching is weird though, like a timing problem almost, unless the game is just alternating sprites at those positions (maybe for animation effects). I wonder if there is anything else interfering with those pins...
I took that photo way back when I first got it, so no time spent.
I think it may be related to other bus activity. Notice how the pattern is static on the NeoGeo logo? The only other access at that point is the 68k program, which probably only runs for a few scanlines during VBlank And during the title sequence everything gets a bit glitchy, because there's ADPCM sound and more CPU activity. You can also kinda see it "ratchet" on the scrolling background during the gameplay demo when sprite slots shift over by one (backgrounds are built by placing a bunch of sprites next to eachother).