.... and the Amigas frequency control is always an integer division of the clock frequency, so no added jitter/aliasing. No other machine in my arsenal of retro systems comes close to play 8 bits samples so flawlessly without interpolation, aliasing or any kind of coloring (except for what the 80's opamps introduces). Of course the samples themselves contain aliasing, but as long as the frequency of a sampled instrument is an integer division of the sample frequency, the final sound will mostly contain harmonic overtones, which often times are quite pleasant and adds to the "Amiga sound".
I modified the Analog output LP filter on my Amiga 500 (one of them ) so that the cutoff frequency is above 22kHz; So no muffled output at all.
For OCS Amigas the maximum sample rate for each audio channel is ~28 kHz in PAL/NTSC modes, but on ECS or AGA Amigas running in "non TV modes" above 15.6 kHz line frequency, the limit is ~56 kHz. This all comes down to how the Amigas "cool" but "complex" DMA subsystem (the Chip RAM bus arbitration) works.
Yeah, amiga pitch range is kinda meh. The SNES DSP can actually go up to almost 128kHz (i.e. 4x the output sample rate, completely pointless), as an artifact of how it decompresses the samples (always reads/decodes(?) 4 input samples at once per 32kHz output sample, but discards it unless it actually has space)
Well, fixed all the apparent bugs and did some more crazy optimizations to get it to withstand the worstcase load (embodied by this scene dumped from Twinkle Star Sprites, wherin the not-really-eponymous explosion effect manages to fill up all 96 sprite slots, causing the border sprites to be dropped)
Here is the NeoGeo rendering test program, readied for public consumption by connoisseurs of the 32MB RAM Module. Since the graphics ROM images, as mentioned, are enormous, I can't attach them,so you'll have to copy your own MAME-style ZIPs into the roms folder and run romconv.rb <romset name> (if it gives you a require error, gem install rubyzip). Then, use the loadit.rb script you may know and love from using the megayume alpha to load the generated CROM file into RAM. While that's going, set the palette, VRAM and SROM files at the bottom of the spin source. Load the spin source. Marvel at the not-quite still frame (there's a feature that replaces the LSBs of tile IDs with a free-running counter for simple zero-overhead animations, so that works even in a static VRAM dump. The dump I included from Samurai Shodown uses a lot of that). twinspri-oflow is that 96 sprites-per-line test scene, btw.
When I posted the Megadrive rendering test, @rogloh managed to knock some cycles loose. Try these onions. I have seen the light and have recognized that the purest truth of the universe is excessive unrolling. I control the cycles, but the cycles really control me.
Well, I guess it's time to start cobbling everything together (well, I'm still missing a YM2610 core...).
And it begins as all good things do: by putting way too much effort into the header ASCII art (well, the MegaYume art is actually just from a generator site and I was yet too lazy to make a proper one, but shushhh)
@Ahle2 said:
.... and the Amigas frequency control is always an integer division of the clock frequency, so no added jitter/aliasing. No other machine in my arsenal of retro systems comes close to play 8 bits samples so flawlessly without interpolation, aliasing or any kind of coloring (except for what the 80's opamps introduces). Of course the samples themselves contain aliasing, but as long as the frequency of a sampled instrument is an integer division of the sample frequency, the final sound will mostly contain harmonic overtones, which often times are quite pleasant and adds to the "Amiga sound".
I modified the Analog output LP filter on my Amiga 500 (one of them ) so that the cutoff frequency is above 22kHz; So no muffled output at all.
There are no filters in my P2 "Paula style" audio implementation... at all
A dark side of Paula approach is the low frequency precision. At the higher frequencies (period=~100) the frequency step is about 20 cents (20/100 of the semitone). There is not possible for example to make a "mind machine" out of this, where you have to control the frequency with a high precision. Of course, we have no Amiga, we have "only" a P2... so I of course enabled fractional "sample skip" in my driver to enable precise frequency control at the cost of aliasing if the skip is not integer. The real solution should be a 354 MHz clocked Paula. Maybe... with a P3.
@evanh said:
@Ahle2 said:
... running in "non TV modes" above 15.6 kHz line frequency, ...
A big hmmmmm!
Amiga fetches audio samples every display line. There is a limit of sample number it can get at one display line (=64 us) and this limits the minimal period for a Paula.
AGA is configurable, you can set a resolution and a frame rate to what you want to.
More display lines+higher pixel clocks = more audio samples can be loaded via DMA per video frame = the period can be set lower
@Wuerfel_21 said:
Here is the NeoGeo rendering test program, readied for public consumption by connoisseurs of the 32MB RAM Module. Since the graphics ROM images, as mentioned, are enormous, I can't attach them,so you'll have to copy your own MAME-style ZIPs into the roms folder and run romconv.rb <romset name> (if it gives you a require error, gem install rubyzip). Then, use the loadit.rb script you may know and love from using the megayume alpha to load the generated CROM file into RAM. While that's going, set the palette, VRAM and SROM files at the bottom of the spin source. Load the spin source. Marvel at the not-quite still frame (there's a feature that replaces the LSBs of tile IDs with a free-running counter for simple zero-overhead animations, so that works even in a static VRAM dump. The dump I included from Samurai Shodown uses a lot of that). twinspri-oflow is that 96 sprites-per-line test scene, btw.
When I posted the Megadrive rendering test, @rogloh managed to knock some cycles loose. Try these onions. I have seen the light and have recognized that the purest truth of the universe is excessive unrolling. I control the cycles, but the cycles really control me.
Your announcements often a little cryptic for me - are you saying you've managed the 96 sprites per scanline now? If so, well done! I'd try some of this code here but don't have any roms myself.
Well, I guess it's time to start cobbling everything together (well, I'm still missing a YM2610 core...).
Cool you are making good progress . How does the COG allocation look for a project such as this?
I'm somewhat interested in this as I have this idea for repurposing this cheesy little dirt cheap handheld toy game I picked up a while back, with a 2.4 inch LCD based on IL9341 (320x240) or something like that which in theory can do 60fps over SPI at least on a Raspi, so probably also on a P2-EC32MB, but it might need its own custom output driver which I could try to write if there is a spare COG left (or reuse the existing video one). Ideally I could find a 2.4 inch LCD that could take VGA, but not sure if they do at this size (EDIT- just found there are some that use the ST7789V with 18bit parallel RGB + CLK,DE,H,V sync which are probably easy to integrate). This would be a neat project to hack up - I could either go a P2 platform or maybe use the Raspi zero with MAME etc (both systems would probably just fit inside this gutted device with a 2Ah Lipo in there as well). P2 would be faster to boot which is a real advantage.
@Wuerfel_21 said:
Here is the NeoGeo rendering test program, readied for public consumption by connoisseurs of the 32MB RAM Module. Since the graphics ROM images, as mentioned, are enormous, I can't attach them,so you'll have to copy your own MAME-style ZIPs into the roms folder and run romconv.rb <romset name> (if it gives you a require error, gem install rubyzip). Then, use the loadit.rb script you may know and love from using the megayume alpha to load the generated CROM file into RAM. While that's going, set the palette, VRAM and SROM files at the bottom of the spin source. Load the spin source. Marvel at the not-quite still frame (there's a feature that replaces the LSBs of tile IDs with a free-running counter for simple zero-overhead animations, so that works even in a static VRAM dump. The dump I included from Samurai Shodown uses a lot of that). twinspri-oflow is that 96 sprites-per-line test scene, btw.
When I posted the Megadrive rendering test, @rogloh managed to knock some cycles loose. Try these onions. I have seen the light and have recognized that the purest truth of the universe is excessive unrolling. I control the cycles, but the cycles really control me.
Your announcements often a little cryptic for me - are you saying you've managed the 96 sprites per scanline now? If so, well done! I'd try some of this code here but don't have any roms myself.
Yep, 96 sprites per line go brr on the testbed. Though the memory code is not final, it's just cobbled together to only service the sprite data. I want to try using the pulse mode for CS, so I don't need to wait around for a transfer to actually complete (thus higher throughput and lower latency).
Also, a neat thing: aside from the obvious way to acquire ROMs, I hear that if you purchase one of the NeoGeo games available on gog.com for ~6$, you can just copy out the ROM files (not sure what BIOS that comes with though - we'll need an AES BIOS since MVS is going to choke on lack of NVRAM/RTC).
And yes, I acknowledge that I sometimes forget to include relevant information amongst all the odd speech patterns I can't stop myself from doing.
Well, I guess it's time to start cobbling everything together (well, I'm still missing a YM2610 core...).
Cool you are making good progress . How does the COG allocation look for a project such as this?
It's going to be roughly the same as MegaYume, but with the Spin background process kicked out to make room for the PSRAM driver (and also because I need the hub memory). So we get (in no particular order):
68000 emulator
PSRAM arbiter
Sprite controller (generate addresses for active sprites on line)
Blitter (blit loaded sprite data to line buffer, also renders fix overlay)
Z80 emulator
YM2610 audio
Video output
USB
I'm somewhat interested in this as I have this idea for repurposing this cheesy little dirt cheap handheld toy game I picked up a while back, with a 2.4 inch LCD based on IL9341 (320x240) or something like that which in theory can do 60fps over SPI at least on a Raspi, so probably also on a P2-EC32MB, but it might need its own custom output driver which I could try to write if there is a spare COG left (or reuse the existing video one). Ideally I could find a 2.4 inch LCD that could take VGA, but not sure if they do at this size (EDIT- just found there are some that use the ST7789V with 18bit parallel RGB + CLK,DE,H,V sync which are probably easy to integrate). This would be a neat project to hack up - I could either go a P2 platform or maybe use the Raspi zero with MAME etc (both systems would probably just fit inside this gutted device with a 2Ah Lipo in there as well). P2 would be faster to boot which is a real advantage.
ILI9341 and ST7789V are both 240x320 portrait mode drivers with only a single page of internal memory, so regardless of what you do, when you feed horizontally scanning data to them you'll get horrible diagonal tearing. There does exist an ILI9342 that is proper 320x240 landscape, but it is for some reason significantly more rare than its portrait brethren. (Who on god's green earth asked for portrait scan displays, anyways?)
And yes, straight RGB interface would be easier to hack onto the exisiting MegaVGA video code (i believe that 90% of the pieces are in place for that due to HDMI support), but you could do SPI just as well. Just make sure to adhere to the same SDTV-ish line timing because everything else is timed around the video cog.
Decided to implement loading from SD first this time. I thought it'd be really slow, but it somehow isn't. This is with data mangling (converting sprite tiles to a linear chunky format (thus showing a pair of files, since the bitplanes are split across two files (corresponding to two physical ROMs on a cartridge, because no one makes 32 bit mask ROM chips, I guess)), reordering fix tile data so all the nibbles for one line are adjacent, byte-swapping program ROM)
And yea, the video timings need to be fine-tuned yet.
@Wuerfel_21 said:
ILI9341 and ST7789V are both 240x320 portrait mode drivers with only a single page of internal memory, so regardless of what you do, when you feed horizontally scanning data to them you'll get horrible diagonal tearing. There does exist an ILI9342 that is proper 320x240 landscape, but it is for some reason significantly more rare than its portrait brethren. (Who on god's green earth asked for portrait scan displays, anyways?)
Ok thanks, this is very good to know. I didn't even realize that yet and it would be bad to go down that path only to encounter it later once it's all too late.
And yes, straight RGB interface would be easier to hack onto the exisiting MegaVGA video code (i believe that 90% of the pieces are in place for that due to HDMI support), but you could do SPI just as well. Just make sure to adhere to the same SDTV-ish line timing because everything else is timed around the video cog.
I'll probably keep my eye out for a small LCD replacement that does native landscape with parallel RGB, although for the many MAME games (using a different form factor device) going portrait is probably a good option, that one maybe done with a Raspi setup instead of P2. But you are right, the scanning doesn't need to be portrait. Those original portrait arcade games had CRTs that were just rotated 90 degrees but kept the scanning horizontal along the longer axis AFAIK.
I have this 90 degrees type of problem in the robot. We used a horizontal display in a portrait mode. I used one of version of my hng driver and "translated" x and y in basic graphics functions (eg. putpixel), so it works in the portrait mode from the programmer's perspective.
Have you tried figuring out what the LCD that comes in the cheapo handheld does? Looks to be some sort of terrible famiclone, so the LCD would have to be landscape scan and probably(tm) is 320x240. Or they are using a portrait scan screen with internal buffer and just lol at the tearing.
The scan direction isn't an issue for a Pi. The game renders a full frame into a buffer and hands it to the OS to put onto the display, which it can do in any orientation. Downside is that no matter how you slice it, there's some 16ms of added latency (could be less if the frame doesn't actually take 16ms to process, but I don't think anyone really does that because it makes lag spikes worse).
And yeah, old vertical screen arcade games really just use a normal monitor turned on its side. Interestingly, some arcade-to-console ports of the latter days (Ikaruga is the meme for this) have a "tate (->'vertical') mode" where instead of pillarboxing the portrait game onto your landscape TV, you'd turn your TV on its side to get the full vertical screen. Mental.
Interesting maybe-coincidence: such a rotated monitor scans top->bottom,right->left, same way that vertical(->tate) japanese is written.
@rogloh said:
Those original portrait arcade games had CRTs that were just rotated 90 degrees but kept the scanning horizontal along the longer axis AFAIK.
Space Invaders is the classic example of a rotated CRT. Most SI emulators translate the address when each video byte is written but the P2 doesn't have to do that as it can read the original SI VRAM and rotate on the fly.
Ok, slight problem: Neo-Geo memory map is quite a bit more complicated, so I'll have to muck about with the 68000 quite a bit (and somewhat duplicate a lot of code, since every memory handler needs to exist in 8,16,32 bit variants). Too tired to deal with that today.
@Wuerfel_21 said:
Have you tried figuring out what the LCD that comes in the cheapo handheld does? Looks to be some sort of terrible famiclone, so the LCD would have to be landscape scan and probably(tm) is 320x240. Or they are using a portrait scan screen with internal buffer and just lol at the tearing.
I did have a quick look a while back. It seemed to use some type of 8 bit digital interface when I was probing with the scope. I'll have to open it again at some point to try to identify the actual controller if its visible on the LCD at all (I don't recall if it was). Not sure if it was scanning in vertical or horizontal direction as I've not really played the included games, they are all pretty crappy ones I don't even know. There could be tearing. I'll look again today.
To find one of these I think they were called Flea Market handheld games. But there are plenty of others, some of which could be better to mod, have more buttons, or have nicer/bigger screens etc. I just saw this for like $10 or something in some bargain bin locally and grabbed it as I thought the case itself could be useful down the line for something portable.
@Rayman said:
@rogloh That's an interesting idea! I've got a box full of good quality 320x240 LCDs. This might be a nice application for them.
I opened this thing again to check the LCD and took a few more photos which I've added below. You can now see the innards. Unfortunately the controller chip is not showing. Maybe the serial number on the cable identifies the type of LCD...?
There's room in this thing for either a Raspi Zero or a P2 Edge board. Not sure about the connector for the P2, would probably have to solder gold edge fingers directly to a flat flex cable or something.
There's also room for a 2Ah Lipo if the 3xAAA battery holder is dremelled out, along with space for a small amount of circuitry at the edges for USB power/charge/prop-plug input, a tiny speaker amp etc, or probably even an HDMI connector. That internal battery holder needs to be removed to grant height for the Lipo and circuit boards but its cover is retained for the existing neat look at the back of the case. Height from the back of the single sided board to the back edge of the case is about 11-12mm or so. Certainly enough for the 5mm battery and either of the Pi/P2 boards. A 2.4inch VGA display would be dead easy to hack into this and the tracks could be cut to the buttons and tapped into.
Edit: actually if you retained the main board you could probably tap into the existing amp chip for audio so then all you'd need is a Lipo 5V boost/charge board and a propplug for P2 with the LCD and some cables.
@Wuerfel_21 said:
Ok, slight problem: Neo-Geo memory map is quite a bit more complicated, so I'll have to muck about with the 68000 quite a bit (and somewhat duplicate a lot of code, since every memory handler needs to exist in 8,16,32 bit variants). Too tired to deal with that today.
Oh yeah i'm feeling it ~
When I get something that vaguely works, I think I'll want to merge all these ROM setups (remember, there's 8/16/32 variants of each) into one and use an EXECF table.
EDIT: lmao ran out of cog memory, so I guess I'll have to EXECF it up right now
Does this overhead have to happen on every single memory access? I'm guessing it would unless perhaps there is a fast way to compare against the last access type and keep some parameters from the prior access when you can. That only makes sense though if the extra compare operation for allowing that doesn't introduce even more cycles that it saves you.
Yep, this happens on every access. However, it (and the operand decode that calls it) only happens once in a RMW operation (since it sets up both the read and write function). Also, the RAM setup code is significantly shorter (taking advantage of the RAM being 64K and aligned in Hub). Read through the 68000 core as it is in MegaYume to get an idea of how it all fits together. I think it's decently straightforward.
And now I realize that using LUT sharing on the PSRAM cog is probably not the best idea. Only because of that accursed nibble replication table. Oh well, COGATN it is.
@Wuerfel_21 said:
And now I realize that using LUT sharing on the PSRAM cog is probably not the best idea. Only because of that accursed nibble replication table. Oh well, COGATN it is.
Yeah that would be a problem.... you cannot use the streamer with LUT translation AND also LUT sharing (for your mailbox/notification use) from the paired COG without conflicts if they are simultaneously accessing the same memory because they share a common port to the memory and the write takes priority, corrupting the streamer.
Well, I think I got the 68k memory code together. Now I just need to add the I/O and interrupts then I should be able to start the treacherous process of debugging. The AES BIOS allegedly doesn't need the Z80 subsystem at all, so I guess I should get the logo screen to appear fairly easily.
Welp, decided to skip the IO stuff for now to just try booting into the BIOS (in the hopes that it'd write to palette RAM to indicate success).
Oddly enough it seems to execute something, but dies after a second or so. Sometimes in the middle of a DEBUG print?!!?!? The "Got request" line is printed by the PSRAM cog while the 68k should be hanging in a WAITATN, so what is killing it while inside the debugger?
EDIT: I once got it to run to what seems like a natural ending point (address error) by lowering clkfreq all the way to 322 (from the ~338 I want to use), but that's also not consistent, so I think that's not the issue.
EDIT2: I forgot to mention, I also tried killing the video rendering system before starting the CPU/PSRAM, doesn't matter, either.
EDIT3: Ok, I think loadp2's terminal is just having a normal one. Always works in PropTool's janky debug viewer (but I can verify that regardless, it gets to the address error, by setting the backdrop color at that point)
Comments
.... and the Amigas frequency control is always an integer division of the clock frequency, so no added jitter/aliasing. No other machine in my arsenal of retro systems comes close to play 8 bits samples so flawlessly without interpolation, aliasing or any kind of coloring (except for what the 80's opamps introduces). Of course the samples themselves contain aliasing, but as long as the frequency of a sampled instrument is an integer division of the sample frequency, the final sound will mostly contain harmonic overtones, which often times are quite pleasant and adds to the "Amiga sound".
I modified the Analog output LP filter on my Amiga 500 (one of them
) so that the cutoff frequency is above 22kHz; So no muffled output at all. 
Max sample rate was its biggest limitation. It really needed more headroom there exactly because of the per-channel variable control.
For OCS Amigas the maximum sample rate for each audio channel is ~28 kHz in PAL/NTSC modes, but on ECS or AGA Amigas running in "non TV modes" above 15.6 kHz line frequency, the limit is ~56 kHz. This all comes down to how the Amigas "cool" but "complex" DMA subsystem (the Chip RAM bus arbitration) works.
A big hmmmmm!
Yeah, amiga pitch range is kinda meh. The SNES DSP can actually go up to almost 128kHz (i.e. 4x the output sample rate, completely pointless), as an artifact of how it decompresses the samples (always reads/decodes(?) 4 input samples at once per 32kHz output sample, but discards it unless it actually has space)
huh. I guess it kinda works? Some sort of issue with the tile IDs though. Also the players aren't showing up.
Moral of the story, don't accidentally use the palette ID lower nibble as the top nibble of the tile ID.
IDK where the players are, they seem to be late to the party.
Well, fixed all the apparent bugs and did some more crazy optimizations to get it to withstand the worstcase load (embodied by this scene dumped from Twinkle Star Sprites, wherin the not-really-eponymous explosion effect manages to fill up all 96 sprite slots, causing the border sprites to be dropped)
Here is the NeoGeo rendering test program, readied for public consumption by connoisseurs of the 32MB RAM Module. Since the graphics ROM images, as mentioned, are enormous, I can't attach them,so you'll have to copy your own MAME-style ZIPs into the roms folder and run
romconv.rb <romset name>(if it gives you a require error,gem install rubyzip). Then, use theloadit.rbscript you may know and love from using the megayume alpha to load the generated CROM file into RAM. While that's going, set the palette, VRAM and SROM files at the bottom of the spin source. Load the spin source. Marvel at the not-quite still frame (there's a feature that replaces the LSBs of tile IDs with a free-running counter for simple zero-overhead animations, so that works even in a static VRAM dump. The dump I included from Samurai Shodown uses a lot of that).twinspri-oflowis that 96 sprites-per-line test scene, btw.When I posted the Megadrive rendering test, @rogloh managed to knock some cycles loose. Try these onions. I have seen the light and have recognized that the purest truth of the universe is excessive unrolling. I control the cycles, but the cycles really control me.
Well, I guess it's time to start cobbling everything together (well, I'm still missing a YM2610 core...).
And it begins as all good things do: by putting way too much effort into the header ASCII art (well, the MegaYume art is actually just from a generator site and I was yet too lazy to make a proper one, but shushhh)
Proptool doesn't like the fullwidth text though, so I guess the version in the actual sources will need to be nerfed to ASCII only.
There are no filters in my P2 "Paula style" audio implementation... at all
A dark side of Paula approach is the low frequency precision. At the higher frequencies (period=~100) the frequency step is about 20 cents (20/100 of the semitone). There is not possible for example to make a "mind machine" out of this, where you have to control the frequency with a high precision. Of course, we have no Amiga, we have "only" a P2... so I of course enabled fractional "sample skip" in my driver to enable precise frequency control at the cost of aliasing if the skip is not integer. The real solution should be a 354 MHz clocked Paula. Maybe... with a P3.
Amiga fetches audio samples every display line. There is a limit of sample number it can get at one display line (=64 us) and this limits the minimal period for a Paula.
AGA is configurable, you can set a resolution and a frame rate to what you want to.
More display lines+higher pixel clocks = more audio samples can be loaded via DMA per video frame = the period can be set lower
Now, this is offtopic. Stop.
Your announcements often a little cryptic for me - are you saying you've managed the 96 sprites per scanline now? If so, well done! I'd try some of this code here but don't have any roms myself.
Cool you are making good progress . How does the COG allocation look for a project such as this?
I'm somewhat interested in this as I have this idea for repurposing this cheesy little dirt cheap handheld toy game I picked up a while back, with a 2.4 inch LCD based on IL9341 (320x240) or something like that which in theory can do 60fps over SPI at least on a Raspi, so probably also on a P2-EC32MB, but it might need its own custom output driver which I could try to write if there is a spare COG left (or reuse the existing video one). Ideally I could find a 2.4 inch LCD that could take VGA, but not sure if they do at this size (EDIT- just found there are some that use the ST7789V with 18bit parallel RGB + CLK,DE,H,V sync which are probably easy to integrate). This would be a neat project to hack up - I could either go a P2 platform or maybe use the Raspi zero with MAME etc (both systems would probably just fit inside this gutted device with a 2Ah Lipo in there as well). P2 would be faster to boot which is a real advantage.
Yep, 96 sprites per line go brr on the testbed. Though the memory code is not final, it's just cobbled together to only service the sprite data. I want to try using the pulse mode for CS, so I don't need to wait around for a transfer to actually complete (thus higher throughput and lower latency).
Also, a neat thing: aside from the obvious way to acquire ROMs, I hear that if you purchase one of the NeoGeo games available on gog.com for ~6$, you can just copy out the ROM files (not sure what BIOS that comes with though - we'll need an AES BIOS since MVS is going to choke on lack of NVRAM/RTC).
And yes, I acknowledge that I sometimes forget to include relevant information amongst all the odd speech patterns I can't stop myself from doing.
It's going to be roughly the same as MegaYume, but with the Spin background process kicked out to make room for the PSRAM driver (and also because I need the hub memory). So we get (in no particular order):
ILI9341 and ST7789V are both 240x320 portrait mode drivers with only a single page of internal memory, so regardless of what you do, when you feed horizontally scanning data to them you'll get horrible diagonal tearing. There does exist an ILI9342 that is proper 320x240 landscape, but it is for some reason significantly more rare than its portrait brethren. (Who on god's green earth asked for portrait scan displays, anyways?)
And yes, straight RGB interface would be easier to hack onto the exisiting MegaVGA video code (i believe that 90% of the pieces are in place for that due to HDMI support), but you could do SPI just as well. Just make sure to adhere to the same SDTV-ish line timing because everything else is timed around the video cog.
Decided to implement loading from SD first this time. I thought it'd be really slow, but it somehow isn't. This is with data mangling (converting sprite tiles to a linear chunky format (thus showing a pair of files, since the bitplanes are split across two files (corresponding to two physical ROMs on a cartridge, because no one makes 32 bit mask ROM chips, I guess)), reordering fix tile data so all the nibbles for one line are adjacent, byte-swapping program ROM)
And yea, the video timings need to be fine-tuned yet.
Ok thanks, this is very good to know. I didn't even realize that yet and it would be bad to go down that path only to encounter it later once it's all too late.
I'll probably keep my eye out for a small LCD replacement that does native landscape with parallel RGB, although for the many MAME games (using a different form factor device) going portrait is probably a good option, that one maybe done with a Raspi setup instead of P2. But you are right, the scanning doesn't need to be portrait. Those original portrait arcade games had CRTs that were just rotated 90 degrees but kept the scanning horizontal along the longer axis AFAIK.
I have this 90 degrees type of problem in the robot. We used a horizontal display in a portrait mode. I used one of version of my hng driver and "translated" x and y in basic graphics functions (eg. putpixel), so it works in the portrait mode from the programmer's perspective.
We used this thing for the robot https://botland.com.pl/wyswietlacze-lcd-tft-i-ips/11933-ekran-dotykowy-h-pojemnosciowy-lcd-tft-5-800x480px-hdmi-usb-do-raspberry-pi-waveshare-14300-5904422318284.html - it's horizontal. Powered by a P2 @ 285 MHz (28.5 MHz clock); I don't know how to use touch option here, it's USB
but there is a "brother" https://botland.com.pl/wyswietlacze-raspberry-pi/4467-ekran-dotykowy-rezystancyjny-lcd-tft-5-800x480px-hdmi-gpio-dla-raspberry-pi-432bzero-waveshare-10563-5904422371364.html which uses SPI for a touch panel so maybe it can be used with a P2 for such a small game emulator (or audio module)
Have you tried figuring out what the LCD that comes in the cheapo handheld does? Looks to be some sort of terrible famiclone, so the LCD would have to be landscape scan and probably(tm) is 320x240. Or they are using a portrait scan screen with internal buffer and just lol at the tearing.
The scan direction isn't an issue for a Pi. The game renders a full frame into a buffer and hands it to the OS to put onto the display, which it can do in any orientation. Downside is that no matter how you slice it, there's some 16ms of added latency (could be less if the frame doesn't actually take 16ms to process, but I don't think anyone really does that because it makes lag spikes worse).
And yeah, old vertical screen arcade games really just use a normal monitor turned on its side. Interestingly, some arcade-to-console ports of the latter days (Ikaruga is the meme for this) have a "tate (->'vertical') mode" where instead of pillarboxing the portrait game onto your landscape TV, you'd turn your TV on its side to get the full vertical screen. Mental.
Interesting maybe-coincidence: such a rotated monitor scans top->bottom,right->left, same way that vertical(->tate) japanese is written.
aaand done that. NTSC timing is hardware accurate and yep, it fits squarely within the capture card frame.
Space Invaders is the classic example of a rotated CRT. Most SI emulators translate the address when each video byte is written but the P2 doesn't have to do that as it can read the original SI VRAM and rotate on the fly.
Ok, slight problem: Neo-Geo memory map is quite a bit more complicated, so I'll have to muck about with the 68000 quite a bit (and somewhat duplicate a lot of code, since every memory handler needs to exist in 8,16,32 bit variants). Too tired to deal with that today.
I did have a quick look a while back. It seemed to use some type of 8 bit digital interface when I was probing with the scope. I'll have to open it again at some point to try to identify the actual controller if its visible on the LCD at all (I don't recall if it was). Not sure if it was scanning in vertical or horizontal direction as I've not really played the included games, they are all pretty crappy ones I don't even know. There could be tearing. I'll look again today.
To find one of these I think they were called Flea Market handheld games. But there are plenty of others, some of which could be better to mod, have more buttons, or have nicer/bigger screens etc. I just saw this for like $10 or something in some bargain bin locally and grabbed it as I thought the case itself could be useful down the line for something portable.
@rogloh That's an interesting idea! I've got a box full of good quality 320x240 LCDs. This might be a nice application for them.
I opened this thing again to check the LCD and took a few more photos which I've added below. You can now see the innards. Unfortunately the controller chip is not showing. Maybe the serial number on the cable identifies the type of LCD...?
There's room in this thing for either a Raspi Zero or a P2 Edge board. Not sure about the connector for the P2, would probably have to solder gold edge fingers directly to a flat flex cable or something.
There's also room for a 2Ah Lipo if the 3xAAA battery holder is dremelled out, along with space for a small amount of circuitry at the edges for USB power/charge/prop-plug input, a tiny speaker amp etc, or probably even an HDMI connector. That internal battery holder needs to be removed to grant height for the Lipo and circuit boards but its cover is retained for the existing neat look at the back of the case. Height from the back of the single sided board to the back edge of the case is about 11-12mm or so. Certainly enough for the 5mm battery and either of the Pi/P2 boards. A 2.4inch VGA display would be dead easy to hack into this and the tracks could be cut to the buttons and tapped into.
Edit: actually if you retained the main board you could probably tap into the existing amp chip for audio so then all you'd need is a Lipo 5V boost/charge board and a propplug for P2 with the LCD and some cables.
Oh yeah i'm feeling it ~
When I get something that vaguely works, I think I'll want to merge all these ROM setups (remember, there's 8/16/32 variants of each) into one and use an EXECF table.
EDIT: lmao ran out of cog memory, so I guess I'll have to EXECF it up right now
Does this overhead have to happen on every single memory access? I'm guessing it would unless perhaps there is a fast way to compare against the last access type and keep some parameters from the prior access when you can. That only makes sense though if the extra compare operation for allowing that doesn't introduce even more cycles that it saves you.
Yep, this happens on every access. However, it (and the operand decode that calls it) only happens once in a RMW operation (since it sets up both the read and write function). Also, the RAM setup code is significantly shorter (taking advantage of the RAM being 64K and aligned in Hub). Read through the 68000 core as it is in MegaYume to get an idea of how it all fits together. I think it's decently straightforward.
And now I realize that using LUT sharing on the PSRAM cog is probably not the best idea. Only because of that accursed nibble replication table. Oh well, COGATN it is.
Yeah that would be a problem.... you cannot use the streamer with LUT translation AND also LUT sharing (for your mailbox/notification use) from the paired COG without conflicts if they are simultaneously accessing the same memory because they share a common port to the memory and the write takes priority, corrupting the streamer.
Well, I think I got the 68k memory code together. Now I just need to add the I/O and interrupts then I should be able to start the treacherous process of debugging. The AES BIOS allegedly doesn't need the Z80 subsystem at all, so I guess I should get the logo screen to appear fairly easily.
Welp, decided to skip the IO stuff for now to just try booting into the BIOS (in the hopes that it'd write to palette RAM to indicate success).
Oddly enough it seems to execute something, but dies after a second or so. Sometimes in the middle of a DEBUG print?!!?!? The "Got request" line is printed by the PSRAM cog while the 68k should be hanging in a WAITATN, so what is killing it while inside the debugger?
EDIT: I once got it to run to what seems like a natural ending point (address error) by lowering clkfreq all the way to 322 (from the ~338 I want to use), but that's also not consistent, so I think that's not the issue.
EDIT2: I forgot to mention, I also tried killing the video rendering system before starting the CPU/PSRAM, doesn't matter, either.
EDIT3: Ok, I think loadp2's terminal is just having a normal one. Always works in PropTool's janky debug viewer (but I can verify that regardless, it gets to the address error, by setting the backdrop color at that point)