Spin Hexagon for P2 (Version 1.2)

Wuerfel_21

Here it is, Spin Hexagon for P2.

Unlike the P1 version, this one can be built just by compiling hexagon.spin in flexspin/FlexProp. flexspin 6.9.1 or higher is required. Change pin assignments and video config in platform.spin. Additionally, you will need to copy all the VU and RAW files onto the root of your SD card.

Currently supported input devices are USB keyboards/gamepads and that accessory board with the buttons. There's also some leftover SNES pad reading code, but IDK if that works.

The controls are as follows:

Keyboard	Gamepad	Action
←	Left or Button 5	Turn counter-clockwise
→	Left or Button 6	Turn clockwise
Space	Button 2	Start game
Esc	Button 10	Abort game / Back to menu

PADMAP.TXT is supported. (appid: spinhexagon)

More details on configuring video:

• VIDEO_TYPE should be set to one of VGA,SVIDEO_CVBS,SVIDEO,CVBS. Other types might work, too but are untested at the moment
• VIDEO_RESOLUTION should be zero for SDTV or one of the resolution constants from p2videodrv, such as RES_1024x768.
• VIDEO_PAL enables PAL60 instead of NTSC
• Really high resolutions might require increasing the RENDERCOGS constant

(Game is too big to attach, click here to download Version 1.2)

Old, for reference: 1.1 1.0 RC1 Fourth beta release Third beta release Second beta release First beta release

cgracey

Wuerfel, have you got a video that would give us a preview of what this is like?

Wuerfel_21

Not right now, will see about that. However, it is literally the exact same as the P1 version, but in higher resolution and with smoother color cycling, so the video on that is representative, I think:

cgracey

Super! Thanks, Wuerfel.

rogloh

@Wuerfel_21 I tried running this after following the directions but it stops immediately after it prints this (screen attached). It does seem to read the files off the SD card ok, but can't appear to write to it and just hangs there for minutes before I reset the board. LEDs P56,P57,P60 and P61 are all lit on the P2-EVAL. I have the USB fitted at P48 and the AV board at P0, nothing else.

Might just be flaky SD code and/or my card.

'' Spin Hexagon P2 platform definitions

'' For mono output, set audioRight to -1
audioLeft     = 6 
audioRight    = 7

'' If you don't have SNES controller port, set these to -1
SNES_CLK      = -1
SNES_LATCH    = -1
SNES_PLAYER1  = -1


'' P2 EVAL control board basepin. Set to -1 if not used
CONTROLACC_BASEPIN = -1

'' USB Keyboard/mouse. Set to -1 if not used
  USB0_BASEPIN = 48             ' USB port0/port1 pin block
  NEXT_BASEPIN = 4              ' Add to BASEPIN for next USB port pin
' EVENT_PIN    = BASEPIN        ' BASEPIN is also the EVENT repository
' ACTIVITY_LED = BASEPIN        ' and the port activity LED
  ENABLE_PIN   = 1              ' USB object enables port voltage protection
  DM_PIN       = 2              ' Add to BASEPIN
' DP_PIN       = BASEPIN + 3    ' DP is always DM_PIN + 1
' P2 Eval board user LEDs (active low) lit if an USB port has a fatal error:
  USB0_ERROR_LED    = 56


VIDEO_BASEPIN = 0 
VIDEO_VSYNC   = 0+4 ' only for VGA

'' SD card
SD_DO = 58
SD_CLK = 61
SD_DI = 59
SD_SELECT = 60

PUB getoffmylawnproptoolaaaaaaa

Wuerfel_21

@rogloh

• You really need the latest flexspin git build, otherwise the keyboard won't work. It also makes the garbage characters on the loading screen go away.
• I don't think that hang as anything to do with that though. What kind of card do you have and how many files are on it? If the answer to the latter is "many" than try with an empty one. I really need to investigate a better FS solution.
• As for a workaround, try manually creating a 512 byte file full of zeroes and name it HEXAGON.SAV

rogloh

Well I did download the latest of flexprop and flexspin (v5.1.1 dated Feb 21), as your included build was Windows only and I have a Mac. But it was the latest version I could see on git and there do not appear to be other checkins in the last 5 days, so I guessed that should be the latest and therefore ok. Maybe not if some weird characters after the filename are still being printed.

I did the 512 byte dummy HEXAGON.SAV file thing. It now gets slightly further and says "Save file read OK!" now but still hangs after that in the same way. Not sure what is going on.

It's a Patriot 2GB micro SD card. I'll see what else I can dig up and try instead perhaps. There were some other files/folders on it. 84 files total in root and 2 sub-folders, including your files in the root level. 65MB total. FAT16 format, maybe it needs to be FAT32?

Wuerfel_21

Hanging after the "Save file read OK!" bit is weird. The next thing that should happen is saving the save data back (done to reduce the audio disturbance caused by the first write. I have no idea why that happens, btw, saving never caused audio issues in the P1 version and that had much smaller buffers.)

I think I found the problem though. I think the 2GB card is the issue. Try replacing this file, I think someone put a SHR where there should be a SHL.

Wuerfel_21

By "latest git build" I mean building from the latest source. The necessary fixes are less than 5 days old.
(I found and reported so many flexspin bugs while making the P1 version... There's something about this game and compiler bugs.)

rogloh

Aha, well that wasn't clear.

By the way I debugged it a bit and was able to get it drawing the title screen if I enabled CHEATZ as 2 but sill no keyboard response so I guess that bug is something you fixed in your source.

Update: Also with that sdspi_with_audio.spin2 updated I didn't need the CHEATZ change, with it zeroed again it worked and it said the file was written okay too. No keyboard response so I guess I'm missing your USB fix.

Wuerfel_21

It should also create the save file properly if it isn't there yet, if you want to try that.

I think(tm) you can try changing the line that says long mouseGunk[5] in 1CogKbM_rja3b.spin2 to byte mouseGunk[5*4]. If I understand what the bug was correctly, that is. Not sure if that's really it though.

Alternatively, dig out the accessory board with the buttons. It isn't even that bad.

rogloh

Got it to work from the keyboard in the end, downloaded spin2cpp from its own repo (not the FlexProp repo) and built it then used it to compile your code. Hard game!

Nice to know my video driver is getting some use.

Wuerfel_21

Cool.
Yes, it certainly takes some practice to get good at it.

Care to try if you can get it to do 1920x1080? The relevant instructions are in the first post.

Wuerfel_21

I also think I have an idea as to why the highscore writing sometimes causes audio disturbance in the P2 version, but never in the P1 version: The P1 version never de-asserts the chip-select. It's not necessary, so it doesn't do it. I think that may be preventing the card from entering some sort of power-saving mode when the audio isn't streaming, which causes a long latency on the wirst write after waking up.

rogloh

@Wuerfel_21 said:
Cool.
Yes, it certainly takes some practice to get good at it.

Care to try if you can get it to do 1920x1080? The relevant instructions are in the first post.

Yeah I got it working as high as 1920x1200 with your suggested resolution changes. It looks good at high resolution. Much crisper than that youtube video above.

It could be good to try with some sort of rotary encoder type of input device to have precise control - the USB keyboard input seems to overshoot or be a little jerky when I press the keys, but I'm not good at it yet. Although you might get caught running out of twist in your hands with that once you reach your limits, but that probably only adds to the fun/frustration. It's certainly an interesting retro looking game.

Update: When I tried 1920x1080 instead of 1920x1200 it hangs in your sdda_start routine. There is still some weird interaction between your SD card mounting, perhaps at particular P2 frequencies that change for different resolutions? This is my concern with any SD drivers that (potentially) were not designed to work across the full P2 frequency range, e.g. if they are using hard coded clock cycle timeouts, or depend on fixed IO delays that will change at different P2 frequencies.

Wuerfel_21

@rogloh said:

@Wuerfel_21 said:
Cool.
Yes, it certainly takes some practice to get good at it.

Care to try if you can get it to do 1920x1080? The relevant instructions are in the first post.

Yeah I got it working as high as 1920x1200 with your suggested resolution changes. It looks good at high resolution. Much crisper than that youtube video above.

Update: When I tried 1920x1080 instead of 1920x1200 it hangs in your sdda_start routine. There is still some weird interaction between your SD card mounting, perhaps at particular P2 frequencies that change for different resolutions? This is my concern with any SD drivers that (potentially) were not designed to work across the full P2 frequency range, e.g. if they are using hard coded clock cycle timeouts, or depend on fixed IO delays that will change at different P2 frequencies.

What kinds of frequency does 1920x1080 set? I think 1024x768 already sets a really high one.
But yes, there's some hardcoded timing in that SD driver. I think I may have trimmed the values in the byte sending function too much while trying to eliminate the aforementioned audio stutter while saving. Try increasing the delays in the send_byte function back to 10 (or up them 1 at a time until it works). IDK why that would ever be needed though. Even at 350 MHz a 50MHz cycle would be just 7 P2 cycles. Probably some dumb I/O delay thing. Maybe I can switch it to using smartpins. Eitherhow, I'm not near a P2 right now, so can't do anything.

It could be good to try with some sort of rotary encoder type of input device to have precise control - the USB keyboard input seems to overshoot or be a little jerky when I press the keys, but I'm not good at it yet. Although you might get caught running out of twist in your hands with that once you reach your limits, but that probably only adds to the fun/frustration. It's certainly an interesting retro looking game.

Yeah, rotary control may be interesting, would certainly play very different though. There's a kind of rythm to getting past some of the more difficult patterns. Although now that I think about it, that would be even more difficult on a rotary input, I think.

This is also game that really benefits from low input/display latency. I think the keyboard code is pretty good about that though (wonder how hard it'd be to synchronize its polling with the video driver for consistent latency)

rogloh

Currently:
1920x1080 uses 297MHz,
1024x768 uses 325MHz (only high for coloured text with 5x multiplier, though that could easily be lowered with mono text).
It would be good to decouple audio with SD saving. Presumably this is because a single COG is tied up controlling both aspects but I've not looked into your code. A good mailbox based SD driver that could (independently?) serve two COGs with priority given to your real time COGs might help, unless the filesystem locking requirements affects read access during writes. That would get tricky if file clusters being accessed get moved/deleted during writes for example but I don't know how FAT deals with that. The single threading / exclusive COG access typically prevents those type of issues from rearing up but probably limits the real time responsiveness you might otherwise desire.

pik33

there's some hardcoded timing in that SD driver.

I run Cluso's SD driver @ 360 MHz: it works; the constants are derived fron clkfreq, so I only have to tell it, what the frequency is. Also, modern SD cards accept much more than 50 MHz.

A good mailbox based SD driver that could (independently?) serve two COGs with priority given to your real time COGs might help,

Maybe a caching SD driver? Read next cluster in advance, make a circular buffer for write?

That would get tricky if file clusters being accessed get moved/deleted during writes for example

Then there is a big mess on the file system. File system has to be processed from one point, else the data loss is imminent. Caching/queueing is necessary to avoid this if more than one process can write to FS

FAT32 is not very good for realtime microcontroller accessing. You have to deal with clusters, which can be huge, you have to access FAT and the file in the same time. That's why I want something simpler.

Cluso99

Kye's FAT 32 implements locking, and there is locking on the volume sector of FAT32 (ie on the SD card). Of course continually writing to the same SD sector is a wear levelling problem.

Wuerfel_21

@rogloh said:
Currently:
1920x1080 uses 297MHz,
1024x768 uses 325MHz (only high for coloured text with 5x multiplier, though that could easily be lowered with mono text).

So hegg, why does 1080 not work then?

It would be good to decouple audio with SD saving. Presumably this is because a single COG is tied up controlling both aspects but I've not looked into your code. A good mailbox based SD driver that could (independently?) serve two COGs with priority given to your real time COGs might help, unless the filesystem locking requirements affects read access during writes. That would get tricky if file clusters being accessed get moved/deleted during writes for example but I don't know how FAT deals with that. The single threading / exclusive COG access typically prevents those type of issues from rearing up but probably limits the real time responsiveness you might otherwise desire.

It is a mailbox-driven cog, but it has audio interrupts going on that steal a few cycles and occassionally feed a command back into the SD part. This shouldn't need high speed, anyways. The P1 version does the exact same things, but with really slow code (no interrupts -> have to poll whether it's time for the next sample after every byte read). The P2 version just does it in an interrupt. I verified that it can interrupt the write routine, so the real problem is just that the write command sometimes takes a very long time. I think it must be that aforementioned difference where the P1 version never deselects the card. Not near any propeller stuff this weekend, but I'll try adding an option for the same behavior to sdspi_with_audio

Wuerfel_21

Also, there are zero FAT operations going on while the game is actually running, all raw sector reads/writes. In the P1 version, the loading screen is a seperate binary with its own SD driver that finds the files on the card and makes sure they're not fragmented. It just passes those adresses into the actual game binary. In the P2 version, there's only one binary, but the structure is kept.

rogloh

So hegg, why does 1080 not work then?

Not totally sure. The video is part is okay. I did try to setup a mode of 1024x768 at this 297MHz frequency just to see if it would still have the same issue with the SD hang and it does, so it is not a memory allocation problem, but more a P2 frequency issue with your SD driver operating at 297MHz trying to mount an SD card.

Wuerfel_21

@rogloh said:

So hegg, why does 1080 not work then?

Not totally sure. The video is part is okay. I did try to setup a mode of 1024x768 at this 297MHz frequency just to see if it would still have the same issue with the SD hang and it does, so it is not a memory allocation problem, but more a P2 frequency issue with your SD driver operating at 297MHz trying to mount an SD card.

There's a constant MAXWIDTH that is set to 1920. That controls all the buffer sizes. If tested all that and it is fine.

Have you tried increasing those delays in send_byte that I mentioned?

rogloh

Have you tried increasing those delays in send_byte that I mentioned?

I haven't as yet, did it fix 1080p for you?

Update: just tried it, increasing to waitx delays of 7,8,9 didn't work, but setting them to 10 did allow it to mount at 297MHz (for 1080p and my hacked up 1024x768 mode at 297MHz as well).

Wuerfel_21

I don't know. As I said, I am not at home this weekend.

rogloh

It works, see above.

Wuerfel_21

Hmm... Could @rogloh 's card be so old that it isn't actually a 50 MHz card? Does it have a class rating on it? If not or if it's lower than class 10, that's a possibility. (note: new cards don't have a class rating anymore, either. The A1 symbol (highly desirable for our purposes BTW) and the U1 symbol both imply Class 10, so most microSD cards with those omit the C10 symbol)

evanh

It seems like I've downloaded either an older version or the prop1 version. My platform.spin file doesn't have any USB parameters and it has spi* instead of SD_* and TV_* instead of VIDEO_*.

Wuerfel_21

The download for the P2 version is in the first post. I just edited it to make the link bigger (it's too big to attach to the forum. IDK why I haven't put it on GitHub yet).

You may also need the updated sdspi_with_audio I posted further down.

evanh

Oh, strange, I didn't notice that was a link. Yeah, I ended up on Github.

evanh

Best time is 4.45 seconds. Ouch! No where near enough visual distance to plan a move. Okay, it works. Although, not with -O2 optimising. Just get a blank grey screen then.