Shop OBEX P1 Docs P2 Docs Learn Events
Console Emulation - Page 48 — Parallax Forums

Console Emulation

1424344454648»

Comments

  • Okay, we're dealing with a genuine flexsplorp, I think. @ersmith I think the constant folding is not masking bit shift amounts properly. Too tired to investigate that further today.

    Fixed it up on my end (see github). The listed timing seems to not work on pin 32, I need to change it to this:

    HYPER_LATENCY = 6
    HYPER_WAIT  = HYPER_LATENCY*4 - 2
    HYPER_DELAY = 15
    HYPER_SYNC_CLOCK = false
    HYPER_SYNC_DATA = true
    

    Also, if you need a <=16MB game, try Money Puzzle Exchanger. Probably one of the most funny ones if you plan on never pressing a button.

  • evanhevanh Posts: 15,040

    Bah! I need to kick Roger. The useable range for DELAY is only eight!
    And I see in your init code in megayume_upper.spin2 you've used a fixed offset of -7 to move the min-max out to 7..14. Does that even match the driver code?

  • @evanh said:
    Bah! I need to kick Roger. The useable range for DELAY is only eight!
    And I see in your init code in megayume_upper.spin2 you've used a fixed offset of -7 to move the min-max out to 7..14. Does that even match the driver code?

    Our numbers are independent. I think Ada's matched the HW data sheet more closely whereas mine are purely synthetic and were also offset slightly to range extend a little and also fit in 4 bit driver nibble, but I think they are biased more to the lower end than the higher end. As the frequencies increased perhaps they have topped out vs what we saw with HyperRAM originally?

  • evanhevanh Posts: 15,040

    Roger,
    Are you able to point me to a line number in hyperdrv.spin2 where the offset is applied?

  • Ok I must have been thinking about PSRAM which is where I added it. (psram16drv.spin2)

                                setq    xfreq1                  'reconfigure with single cycle xfreq (sysclk/1)
                                xcont   delay, #0               'configurable fine input delay per P2 clock cycle
                                xcont   #6, #0                  'fixed delay offset to expand delay range
    

    I can't find doing it in the original HyperRAM code but if you want to try to expand it in hyperdrv.spin for the reads you might be able change the waitx #2 instruction below to add some constant value to delay before it gets used further down. But the driver is very tight and does self modify so hopefully this fits and is not gonna break something. Also I hope delay is not somehow used later on, and just gets re-read when required. Been quite a while since I looked at this stuff.

                                waitx   #2                      'delay long enough for DATA bus transfer to complete
                                fltl    datapins                'tri-state DATA bus
                                waitxfi                         'wait for address phase+latency to complete
    p1                          wxpin   #2, clkpin              'adjust transition delay to # clocks
    p2                          setxfrq xfreq2                  'setup streamer frequency
                                wypin   clks, clkpin            'setup number of transfer clocks
                                wrpin   regdatabus, datapins    'setup data bus inputs as registered or not
                                waitx   delay                   'tuning delay for input data reading
                                xinit   xrecv, #0               'start data transfer and then jump to setup code
                                call    resume                  'go see what we will do next while we are streaming
                                waitxfi                         'wait for streaming to finish
                                wrpin   registered, datapins    'prepare data pins for address phase transfer
                _ret_           drvh    cspin                   'de-assert chip select
    
  • roglohrogloh Posts: 5,106
    edited 2023-11-26 05:41

    @evanh Looks like the COG is chockers at 1024 longs so if you want to make a change to make your thermal test run you'll need to save a long elsewhere by commenting something out for your test to make room.

    Also this line worries me:

                                shr     delay, #5 wc            ' a b c d e | g prep delay and test for registered inputs
    

    See the "f" case is missing. That means there is a path where delay is retained from last use. This is the special locked transfer case where you don't yield to other COGs in the middle of the transfer. So long as you don't lock the COG's transfers with the QoS settings you should be okay.

    Update: Actually if this is just for a thermal test you may be able to just hard code this line to be whatever constant delay value you want.
    Eg. change:

                                waitx   delay                   'tuning delay for input data reading
    

    to

                                waitx   #9                   'tuning delay for input data reading
    
  • @evanh said:
    Does that even match the driver code?

    It ought to, but at some point I got tired of fixing bugs with that, so now the high level code only ever writes to memory (writes always work)

  • evanhevanh Posts: 15,040
    edited 2023-11-26 11:14

    I can't find a value that works. I think the Latency value is screwed too. Time to go back to the 96MB add-on.

    EDIT: Doh! I'd forgotten it works fine on base pin P0. The problem is with base pin P32. So the delay is the wrong place to look.

  • Wuerfel_21Wuerfel_21 Posts: 4,311
    edited 2023-11-26 11:30

    @evanh said:
    EDIT: Doh! I'd forgotten it works fine on base pin P0. The problem is with base pin P32. So the delay is the wrong place to look.

    You have updated to the latest commit that actually fixes pin32? The delay does need some tweaking due to trace lenghts or something. See post above, that timing works for me in NeoYume. For MegaYume the stock settings work for pin 32.

  • evanhevanh Posts: 15,040
    edited 2023-11-27 07:54

    Oops, didn't read that very well. What package was updated? Actually, it's Megayume that's been failing for me. I haven't been testing this on Neoyume because I don't have a 16MB game for it.

  • Wuerfel_21Wuerfel_21 Posts: 4,311
    edited 2023-11-27 09:50

    I've updated both the emulators to fix the pin 32 problem. Was that not sufficiently communicated?

  • evanhevanh Posts: 15,040
    edited 2023-11-27 13:21

    In that case it didn't work for me. No worries, I've been busy offline anyway.

    EDIT: Err, my botch up. It's working thanks. I'd gone too far on the config and didn't put everything back.

  • Hey @Wuerfel_21, can you do NES too?

    Elite was the first 3D game, please look at this ... https://www.bbcelite.com

    Mike

  • evanhevanh Posts: 15,040
    edited 2023-12-28 07:34

    I played a lot of Frontier (Elite 2). It did a good job of handling motion in space correctly. Enjoyed docking with full manual controls.

    It struggled with high-G physics though. I couldn't put my finger on what was wrong but some stuff just went batty.

  • @msrobots said:
    Hey @Wuerfel_21, can you do NES too?

    Theoretically yes, but the Famicom/NES is a truly accursed architecture, more than people realize.

    • There's no raster interrupt, instead all sorts of raster effects are achieved by either cycle counting or polling the PPU "sprite 0 hit" bit (weird vestigial hardware collision detector)
    • Every game more complex than the original SMB uses some kind of bankswitch IC. In the simplest case that's just some logic gates to switch program ROM around, but some of these add crazy features such as additional sound channels, remapping video memory at precise points mid-scanline, even a real raster IRQ. There's many, many different cartridge boards that behave very differently.
    • At the tail end the games become too large to fit reasonably in hub ram (freak outlier is Metal Slader Glory, which has 512k PRG + 512k CHR ROM)
  • It was made for bbcmicro, later converted to other 6502. But they are monochrome for the 3d part NES was the only color one in 3d. The menu is in color on all of them.

    Original game was just 22k pure 6502 assembler...

    just looked some video about it. I think I played it on Atari 800 or so.

    Mike

Sign In or Register to comment.