Nah, I think it has come up before that it doesn't like that.
I hate that when even the slightest thing is wrong, the monitor will just do nothing. This is so terribly opaque. With analog video, I can just probe the sync pins to see problems. How is anyone supposed to debug this?
Thinking about testing this on TV... Guess HyperFlash would be more useful, if that's possible...
Going to use VGA to HDMI adapter so can get sound on TV too....
Not sure if HyperFlash has provisions for avoiding read-disturb. Otherwise certain ROM regions (Hblank interrupt...) that are read thousands of times per second might get corrupted rather quickly.
The end goal is to just load the ROM from SD card though.
Also, take care of that aspect ratio. Should be set to 4:3 for correct proportions.
When you say half pixel rate, do you mean sysclock/20 ? If so, then yeah, that won't work because it'll be below 25 Mpixel/s. 25 is the bottom. What you can do is just have huge vblanking instead. That allows extremely low res viewports.
Here's a rule of thump I use for HDMI display timings:
So there is a total of four effective parameters to build complete HDMI timings from:
1 - sysclock frequency (sysfrq)
2 - horzontal resolution (hres)
3 - vertical resolution (vres)
4 - vertical frequency (vfrq)
Remaining timings are:
dotfrq (>= 25 MHz) = sysfrq / 10
htot = hres + 80
hfp = 8
hsw = 64
hbp = 8
vtot = dotfrq / htot / vfrq
vblank = vtot - vres
vsw = 2
vfp = (vblank - vsw) / 2
vbp = vblank - vsw - vfp
negative hsync and vsync both
On the HDMI front, I've hit an unfortunate roadblock - it seems I can not get it to produce pixels at half-rate (NCO $06666667). I tried making only the visible area half-rate, but that's no dice, either. Well, will have to invent some terrible hack to feed pixels manually.
Maybe something from my HDMI/DL stuff can help. There are several NTSC based modes (525 lines total at 60 Hz, CPU= 80/90/100 x NTSC color clock) - pixels can be zoomed horizontally x2 or x4 in the real time inside the driver cog
On my laptop, must have done something wrong installing Ruby...
It doesn't seem to know to use the current folder...
Had to edit loadit.rb and add explicit directory for flexspin and loadp2, like this: #{__dir__}/flexspin -2 #{__dir__}/memstuff/#{loader}.spin2
@Rayman said:
On my laptop, must have done something wrong installing Ruby...
It doesn't seem to know to use the current folder...
Had to edit loadit.rb and add explicit directory for flexspin and loadp2, like this: #{__dir__}/flexspin -2 #{__dir__}/memstuff/#{loader}.spin2
That could happen if current directory isn't on PATH. Which IDK how that'd happen.
Speaking of, you ideally shouldn't copy flexspin into the project directory to begin with. Obnoxiously setting it up such that it lives on PATH is a bit non-obvious.
@Rayman said:
Tried Sonic the Hedgehog, seemed to load OK, but freezes trying to load the first level "Green Hill Zone Act 1".
Ooops, that seems to have broken at some point, indeed. Not sure if its a HyperRAM-specific issue or something to do with the instruction and H timing fixes from earlier. Will have to get the P2EDGE set back up (both to check current version with PSRAM and if that is broken too, to bisect through the older versions).
Sonic 2 and Sonic 3 work though, if you need your fix in the meantime.
On the HDMI front, I've hit an unfortunate roadblock - it seems I can not get it to produce pixels at half-rate (NCO $06666667). I tried making only the visible area half-rate, but that's no dice, either. Well, will have to invent some terrible hack to feed pixels manually.
By mentioning some "terrible hack", perhaps you are ready to try that exactly-seven-month-old-one, yet unborn, of mine:
Sure, it's far from being a thorough description of it (mostly because I can't test any of that (aka, lack of proper DVI/HDMI monitor, and other shortcomes that actually precludes me from realy testing anything)), but, appart from having to re-programm the DVI/HDMI-clock pins within the "smart realm", in order to get the proper phase and frequency, you'll need to scan each line twice (or "thrice", in case of three times), in order to properlly get the "hardware-assisted zoom"...
Doesn't seem to work. I've tried hacking Chip's 800x480 spiral demo to be 400x480 with doubled pixels, but that just doesn't work. The hack is to just run a loop like
vislineH40_hdmi
rep #3,#320
rflong pa
andn pa,#$FF
xcont hack_command,pa
ret
Which works when I hack it into the aforementioned spiral demo or when I force VGA mode to use that codepath, but I'm still not getting HDMI to sync at all.
you'll need to scan each line twice (or "thrice", in case of three times),
That's where the display list can help I have now no problem with horizontal x2, x4 and vertical... what you want. It can be full screen filled with the same lines There is a DL command: repeat n lines, after m lines add q to the display address
I have only one problem with this Sega emulator: still don't have RAM working. If I manage to connect and run them... The connection length can be a killer factor for this. If I manage to run it, maybe I can try to attach this driver's code to it if possible at all
@Rayman said:
Have a Wii classic controller pro and code to run it (I think).
That might be a slight improvement...
Well, if you look at the upper code, I think it will be immediately obvious how to patch in any input device you can dream of.
Though I'm thinking of moving the key remapping into the USB cog itself so that cog0 is free to handle dumping save data to SD card.
you'll need to scan each line twice (or "thrice", in case of three times),
That's where the display list can help I have now no problem with horizontal x2, x4 and vertical... what you want. It can be full screen filled with the same lines There is a DL command: repeat n lines, after m lines add q to the display address
I have only one problem with this Sega emulator: still don't have RAM working. If I manage to connect and run them... The connection length can be a killer factor for this. If I manage to run it, maybe I can try to attach this driver's code to it if possible at all
Probably not. I didn't write a custom video driver for no reason.
- Emu core needs to know the current scanline, even during VBlank
- Megadrive has two resolutions: H32 (256x224) and H40 (320x224). These are both 4:3, so the former needs a different pixel clock (not possible on HDMI, will be pillarboxed and oddly skinny. Most games are H40 though)
- Interlace mode.
In terms of RAM, there is a constant where you can wiggle the read delay up or down a cycle, which may or may not help with longer wire runs.
I have only one problem with this Sega emulator: still don't have RAM working. If I manage to connect and run them... The connection length can be a killer factor for this. If I manage to run it, maybe I can try to attach this driver's code to it if possible at all
Apart from connecting the chip-select and data-transitioning lanes with approximately same-length, loose wires (chip select isn't that critical, but, anyway); as for the clock lanes, you can try 50 Ohm, thin coax cables, but, watchout!!!: try using that yet-old-faithful trick of connecting each shield at just one side of the signal path GND (normally, the reception-side (AKA, ram-side)), so as to mitigate spurs of noise injection.
Current scanline is not a big problem. Vblank has to be splitted to lines in my driver (if it is not already)
Most of monitors displays the picture on all its surface, so all you need for 256x224 is to calculate the horizontal resolution to fit in 9:16 with 4:3 borders - 341x224 or, with doubling, 681x448, the monitor will do the rest
I have only one problem with this Sega emulator: still don't have RAM working. If I manage to connect and run them... The connection length can be a killer factor for this. If I manage to run it, maybe I can try to attach this driver's code to it if possible at all
Apart from connecting the chip-select and data-transitioning lanes with approximately same-length, loose wires (chip select isn't that critical, but, anyway); as for the clock lanes, you can try 50 Ohm, thin coax cables, but, watchout!!!: try using that yet-old-faithful trick of connecting each shield at just one side of the signal path GND (normally, the reception-side (AKA, ram-side)), so as to mitigate spurs of noise injection.
Chip select is really not critical - it's asserted a few cycles before the clock starts and released a few cycles after it stops.
@pik33 said:
Current scanline is not a big problem. Vblank has to be splitted to lines in my driver (if it is not already)
Most of monitors displays the picture on all its surface, so all you need for 256x224 is to calculate the horizontal resolution to fit in 9:16 with 4:3 borders - 341x224 or, with doubling, 681x448, the monitor will do the rest
They both fit in 640x448 (+ 32 extra blank lines to get to 480p), but H32 mode uses a different NCO value to stretch it out. This doesn't quite line up with the sampling of an LCD monitor. Thus the 4x mode - 1280x960 is a an exact multiple of both 256x240 and 320x240, so both should be sharp.
Megadrive has two resolutions: H32 (256x224) and H40 (320x224). These are both 4:3,
That looks like arcade monitor resolutions...
Too bad mine is portrait mode, would be neat to try out...
Yep, totally are. Arcade monitors evolved from repurposed TVs, so they use progressive SDTV resolutions (when they aren't some weird 24kHz thing or vector scan). And the Mega Drive was then in turn designed based on SEGA's arcade graphics hardware.
@Wuerfel_21 Is your emulator available in a Git repository somewhere? I looked but couldn't find it under your Gitlab or Github accounts. Zip files are a pain and also don't maintain executable permissions.
@Wuerfel_21 said:
Not sure if HyperFlash has provisions for avoiding read-disturb. Otherwise certain ROM regions (Hblank interrupt...) that are read thousands of times per second might get corrupted rather quickly.
The end goal is to just load the ROM from SD card though.
The HyperFlash could be useful for multiple game storage which you could rapidly copy into HyperRAM if you are worried about read-disturb. It's limited to 32MB though, so it won't hold too many games, while SD cards are obviously enormous. My driver can map both devices at the same time on the same bus and copy at high speed between them. That could allow a more instant on experience perhaps. Maybe HyperFlash could remember the last game you ran so it starts up immediately again upon power on. Sector erase time is still an issue though.
Another approach is to store real game graphics for a menu system in HyperFlash which can be rapidly navigated through interactively vs reading off an SD, and when do you pick a game from this menu system it would then go read the file off the SD card. All this requires an HyperRAM board though which might become less far common (and more expensive) once the new P2Edge 32MB PSRAM board gets more widely distributed.
@Electrodude said:
@Wuerfel_21 Is your emulator available in a Git repository somewhere? I looked but couldn't find it under your Gitlab or Github accounts. Zip files are a pain and also don't maintain executable permissions.
No, currently not. It will be at some point.
I use Windows on my main PC, so the files don't have permission bits to begin with (Unix permission system is arguably a huge misfeature in Linux - gets in the way when you don't need it (partially aided by sudo literally making you the root user (vs. process elevation on WinNT just enabling extra permissions on your actual user)), not quite fine-grained enough when you do need it (basic protection of system files aside))
Wow that turned into a mini-rant.
Got HDMI working, finally. Looks really great on those small monitors Parallax distributes (despite terrible color reproduction). Will wrap that up and then maybe look into fixing that regression.
@Wuerfel_21 said:
Very fun with PropTool still not supporting preprocessing.
Not! Is there even a safe way to test for PropTool spin vs Flexspin environment that doesn't break PropTool compiles?
This is frustrating... I might be able to put a simple work-around in like having flexspin understand some special comments like {$if flexspin ...} to indicate flexspin only code. Would that help with your project, @Wuerfel_21 ?
@Wuerfel_21 said:
Very fun with PropTool still not supporting preprocessing.
Not! Is there even a safe way to test for PropTool spin vs Flexspin environment that doesn't break PropTool compiles?
This is frustrating... I might be able to put a simple work-around in like having flexspin understand some special comments like {$if flexspin ...} to indicate flexspin only code. Would that help with your project, @Wuerfel_21 ?
Not really. The problem is selecting between different implementations for memory access, which I'd solve with an #ifdef, but proptool doesn't do it, so what I do instead is:
'{
Enabled code
'}
{
Disabled code
'}
Along with labeling them all, that makes it not entirely infuriating to manage.
I think the solution here is to just pester Chip and/or Jeff more.
Comments
Got it! Very cool! Made some notes and took some pics...
Nah, I think it has come up before that it doesn't like that.
I hate that when even the slightest thing is wrong, the monitor will just do nothing. This is so terribly opaque. With analog video, I can just probe the sync pins to see problems. How is anyone supposed to debug this?
Thinking about testing this on TV... Guess HyperFlash would be more useful, if that's possible...
Going to use VGA to HDMI adapter so can get sound on TV too....
Not sure if HyperFlash has provisions for avoiding read-disturb. Otherwise certain ROM regions (Hblank interrupt...) that are read thousands of times per second might get corrupted rather quickly.
The end goal is to just load the ROM from SD card though.
Also, take care of that aspect ratio. Should be set to 4:3 for correct proportions.
When you say half pixel rate, do you mean sysclock/20 ? If so, then yeah, that won't work because it'll be below 25 Mpixel/s. 25 is the bottom. What you can do is just have huge vblanking instead. That allows extremely low res viewports.
Here's a rule of thump I use for HDMI display timings:
My HDMI (LCD) TV has a max limit of about 1023 lines for vblank. I haven't done a lot of testing for this on other monitors and TVs.
Maybe something from my HDMI/DL stuff can help. There are several NTSC based modes (525 lines total at 60 Hz, CPU= 80/90/100 x NTSC color clock) - pixels can be zoomed horizontally x2 or x4 in the real time inside the driver cog
On my laptop, must have done something wrong installing Ruby...
It doesn't seem to know to use the current folder...
Had to edit loadit.rb and add explicit directory for flexspin and loadp2, like this:
#{__dir__}/flexspin -2 #{__dir__}/memstuff/#{loader}.spin2That could happen if current directory isn't on PATH. Which IDK how that'd happen.
Speaking of, you ideally shouldn't copy flexspin into the project directory to begin with. Obnoxiously setting it up such that it lives on PATH is a bit non-obvious.
Got it working on TV with VGA to HDMI adapter with audio.
Made it further into the game, but ran into a brick wall (literally).
My youngest tried it for about 30 seconds and then went away
Think need to find a more interesting game for him...
Think what this needs is wireless game controller...
Have a Wii classic controller pro and code to run it (I think).
That might be a slight improvement...
Tried Sonic the Hedgehog, seemed to load OK, but freezes trying to load the first level "Green Hill Zone Act 1".
Ooops, that seems to have broken at some point, indeed. Not sure if its a HyperRAM-specific issue or something to do with the instruction and H timing fixes from earlier. Will have to get the P2EDGE set back up (both to check current version with PSRAM and if that is broken too, to bisect through the older versions).
Sonic 2 and Sonic 3 work though, if you need your fix in the meantime.
Ok, kids are playing Sonic 2 now, thanks!
By mentioning some "terrible hack", perhaps you are ready to try that exactly-seven-month-old-one, yet unborn, of mine:
Sure, it's far from being a thorough description of it (mostly because I can't test any of that (aka, lack of proper DVI/HDMI monitor, and other shortcomes that actually precludes me from realy testing anything)), but, appart from having to re-programm the DVI/HDMI-clock pins within the "smart realm", in order to get the proper phase and frequency, you'll need to scan each line twice (or "thrice", in case of three times), in order to properlly get the "hardware-assisted zoom"...
https://forums.parallax.com/discussion/comment/1527117/#Comment_1527117
Doesn't seem to work. I've tried hacking Chip's 800x480 spiral demo to be 400x480 with doubled pixels, but that just doesn't work. The hack is to just run a loop like
vislineH40_hdmi rep #3,#320 rflong pa andn pa,#$FF xcont hack_command,pa retWhich works when I hack it into the aforementioned spiral demo or when I force VGA mode to use that codepath, but I'm still not getting HDMI to sync at all.
That's where the display list can help
I have now no problem with horizontal x2, x4 and vertical... what you want. It can be full screen filled with the same lines There is a DL command: repeat n lines, after m lines add q to the display address 
I have only one problem with this Sega emulator: still don't have RAM working. If I manage to connect and run them... The connection length can be a killer factor for this. If I manage to run it, maybe I can try to attach this driver's code to it if possible at all
Well, if you look at the upper code, I think it will be immediately obvious how to patch in any input device you can dream of.
Though I'm thinking of moving the key remapping into the USB cog itself so that cog0 is free to handle dumping save data to SD card.
Probably not. I didn't write a custom video driver for no reason.
- Emu core needs to know the current scanline, even during VBlank
- Megadrive has two resolutions: H32 (256x224) and H40 (320x224). These are both 4:3, so the former needs a different pixel clock (not possible on HDMI, will be pillarboxed and oddly skinny. Most games are H40 though)
- Interlace mode.
In terms of RAM, there is a constant where you can wiggle the read delay up or down a cycle, which may or may not help with longer wire runs.
Apart from connecting the chip-select and data-transitioning lanes with approximately same-length, loose wires (chip select isn't that critical, but, anyway); as for the clock lanes, you can try 50 Ohm, thin coax cables, but, watchout!!!: try using that yet-old-faithful trick of connecting each shield at just one side of the signal path GND (normally, the reception-side (AKA, ram-side)), so as to mitigate spurs of noise injection.
Current scanline is not a big problem. Vblank has to be splitted to lines in my driver (if it is not already)
Most of monitors displays the picture on all its surface, so all you need for 256x224 is to calculate the horizontal resolution to fit in 9:16 with 4:3 borders - 341x224 or, with doubling, 681x448, the monitor will do the rest
Chip select is really not critical - it's asserted a few cycles before the clock starts and released a few cycles after it stops.
They both fit in 640x448 (+ 32 extra blank lines to get to 480p), but H32 mode uses a different NCO value to stretch it out. This doesn't quite line up with the sampling of an LCD monitor. Thus the 4x mode - 1280x960 is a an exact multiple of both 256x240 and 320x240, so both should be sharp.
That looks like arcade monitor resolutions...
Too bad mine is portrait mode, would be neat to try out...
Yep, totally are. Arcade monitors evolved from repurposed TVs, so they use progressive SDTV resolutions (when they aren't some weird 24kHz thing or vector scan). And the Mega Drive was then in turn designed based on SEGA's arcade graphics hardware.
@Wuerfel_21 Is your emulator available in a Git repository somewhere? I looked but couldn't find it under your Gitlab or Github accounts. Zip files are a pain and also don't maintain executable permissions.
The HyperFlash could be useful for multiple game storage which you could rapidly copy into HyperRAM if you are worried about read-disturb. It's limited to 32MB though, so it won't hold too many games, while SD cards are obviously enormous. My driver can map both devices at the same time on the same bus and copy at high speed between them. That could allow a more instant on experience perhaps. Maybe HyperFlash could remember the last game you ran so it starts up immediately again upon power on. Sector erase time is still an issue though.
Another approach is to store real game graphics for a menu system in HyperFlash which can be rapidly navigated through interactively vs reading off an SD, and when do you pick a game from this menu system it would then go read the file off the SD card. All this requires an HyperRAM board though which might become less far common (and more expensive) once the new P2Edge 32MB PSRAM board gets more widely distributed.
No, currently not. It will be at some point.
I use Windows on my main PC, so the files don't have permission bits to begin with (Unix permission system is arguably a huge misfeature in Linux - gets in the way when you don't need it (partially aided by sudo literally making you the root user (vs. process elevation on WinNT just enabling extra permissions on your actual user)), not quite fine-grained enough when you do need it (basic protection of system files aside))
Wow that turned into a mini-rant.
Got HDMI working, finally. Looks really great on those small monitors Parallax distributes (despite terrible color reproduction). Will wrap that up and then maybe look into fixing that regression.
Photo to that extent. Exact 2x scale + digital video = good. View at 100% zoom.
(game is Rocket Knight Adventures if you're wondering)
This is frustrating... I might be able to put a simple work-around in like having flexspin understand some special comments like {$if flexspin ...} to indicate flexspin only code. Would that help with your project, @Wuerfel_21 ?
Not really. The problem is selecting between different implementations for memory access, which I'd solve with an #ifdef, but proptool doesn't do it, so what I do instead is:
'{ Enabled code '} { Disabled code '}Along with labeling them all, that makes it not entirely infuriating to manage.
I think the solution here is to just pester Chip and/or Jeff more.