Normal format is close to optimum - but on a 1050 at least I found reading the sectors in reverse order each track is slightly faster.
Your problem is likely too many CIO calls per given amount of data and/or subsequent processing of the data is taking too long.
You'd probably be better off having a bigger buffer - load chunks of 1K or so then do the processing. A pause every 8 sectors or so is more tolerable than every sector.
In any case, since your using CIO anyway, you're at the mercy of where whatever Dos wrote the files put them. In theory you could change the layout so a file is spread among sectors differently but lots of work and no guarantee of benefit.
A lot of arcade hw was specialized early on. I've recently been looking at Missile Command - it uses a fixed bitmapping system where the last 32 lines is 3 bpp and the remainder only 2 bpp. Also it has an addressing scheme such that most of the machine is only 15-bit addressing but the graphics can either be accessed by direct addressing or by (ind,X) which the board detects and alters the addressing such that the VRam is accessed such that a single pixel appears as the high 2 bits of data.
Some of the early Japanese games like Galaxian, Moon Cresta etc, Frogger used very similar hardware, some were interchangable.
Atari Lunar Lander, many machines were converted to Asteroids.
By the mid 80s, the likes of Atari System 1, 2 emerged, Sega and others had similar standards.
Overall though, arcade systems were usually much bulkier and specialised than an equivalent computer would have been. And the interfacing was usually only to the point of recognising some DIP switches, the joysticks/buttons and coin registers.
Additionally the monitors were usually RGB which at the time was a somewhat expensive option for the home. Doing video for RGB though is somewhat simpler than Chroma/Luma like most home systems did.
Why are todays consoles more advanced? Probably because everyone who likes games either has a console and/or computer. Arcade games are very much a niche market, often running the equivalent of an older PC hardware.
On that note though, it is good to see that a few pinballs are still being produced. Arcade video games are simply a different physical presence where pinball is an entire sensation in itself which probably never will be faithfully reproduced on a computer monitor.
Was the insistence on using a linked sector filesystem, Atari's? Why oh why?
I'd say memory footprint. With a FAT12 system that's a little over 1K to hold a FAT copy in RAM. Alternative to that would be caching part of it but you'd still get the annoyance of having to seek back to read it during file accesses. Bigger clusters = smaller FAT but then even more memory loss due to bigger buffers needed.
Various ways - you could provide a replacement IRQ.
Or you could just read keys manually from the Pokey registers. The keycode register retains the previous keypress so on it's own isn't the full solution.
SKSTAT has the key-down status bit which you should take as prompt to read the keycode.
Debounce can be an issue (one keypress registering 2-3 times) - generally you'd do what the OS does, ie remember previous keypress and maintain a 3 frame timer when keyup occurs. Then ignore any keydown that is the same as the previous for that period.
Looks good - I've never played it so have no idea how it works, I'm guessing he just jumps all the time and there's certain places you can't land and he has energy so can survive a certain number of collisions?
Here's the disassembly I generated. The game code is from $5000-$7FFF. System vectors for NMI/RESET/IRQ @ $7FFA. I left the Ram segment in there, it's somewhat big but provides reference of locations that are directly accessed.
I've spent a few days looking at the game program code (disassembly from IDA Pro) and MAME driver for this game. The MAME driver (C program) is useful in that it provides rough documentation for the hardware used within the machine.
The hope was to be able to take the arcade Rom, put a bit of an emulation wrapper around it and have it run on the computer - both on standard hardware and VBXE.
But... some problems. Looks like there's practically no way the game would work on a standard machine without extensive reworking, and it's likely the reworking would make it too slow anyway.
A few things about the arcade game:
- it uses 256x231 resolution. The horizontal res is somewhat incompatible with Antic modes, it's 4-colour for most of the screen, 8-colour for the bottom 32 pixels. The solution I had in mind was use Antic E with scrolling and pan the view when the cursor gets near the edges of the screen.
With VBXE it wouldn't be so much a problem, it can do 256 pixels in narrow mode although the aspect ratio of the game would be somewhat screwed up, it'd be near 1:1 where the arcade pixels are about 4:3.
- the video RAM uses a weird access/addressing scheme. At first glance it seems ridiculous but the way it works allows accessing pixels on byte boundaries rather than having to do shifts/masks etc. This allows the code to run faster when doing pixel access operations.
The system board uses 1-bit RAMs, so there is little/no wastage. The accesses are only redirected when a CPU instruction with lower 5 bits=00001 is active. Such instructions are the (ind,X) ones - this allows the system to use this addressing scheme for the video Ram with almost 60,000 unique addresses but still allow the system to have a "normal" type memory map where the normal RAM, 12K ROM and IO devices can reside and not resort to any bankswitching tricks.
- it uses a single Pokey at 1.25 MHz and 6502 at ~ 1 MHz. The lower Pokey speed would mean frequency translation or reworking parts of the code would be required (shouldn't be too much work). The lower 6502 speed means the computer has some nice spare cycles to do emulation layer stuff and hopefully still be able to maintain the same pace as the arcade.
- trackball. There are a couple of hardware registers that maintain 4-bit X/Y for the trackball, simulating this should be possible, this is where the extra spare cycles come in handy.
- Interrupts. The game appears to generate IRQs at VSync and periodically during the display (every 64th scanline) - I suspect the scanline IRQs are mainly for reading the trackball position.
I'm thinking this game could probably be made to run under VBXE without too much effort. There are about 30 (ind,X) graphics access instructions in the game although there might be normal access to the video RAM as well (quite possible things like the explosions are done by normal writes to the video RAM).
Pretty sure it's gone completely - there's a system jump table point at $E480 in the XL OS called PUPDIS (PowerUp Display). On 1200XL it displays the rainbow, on other XL OSes it just goes to the Self-Test.
The code that draws the rainbow doesn't seem to be in the ROM on later XL - it appears to use some optimizations to draw it in high RAM, so the amount of ROM used was probably somewhat less than the raw graphics data otherwise would use (it's in Antic D aka Gr. 7 )
You can call up the display within Basic - Z=USR(58496)
Practically everyone agrees the original is a turd but you can't entirely blame the author - he was an employee tasked to do a job and we've all heard the stories of bad games from Atari where the short deadline is a major contributor to the fact.
In the modern day, homebrew can be done at your own pace, plus there's 30 years of accumulated wisdom - practically any 2600 game of the 80s could be recreated today and done better.
Not to take any credit away though... on any machine in 4K this is pretty amazing.