rensoup

they're very close, can't get any c64 emu to play at 50fps (micro64 and vice)... not sure if they're slow or the game is slower on c64

masters of time, such a peculiar tune...

Well... I'm doing my bit ? Every Atari gamer knows Archer Mclean ? I'm surprised that it uses char mode though since there's pretty much no background to restore... It was an awesome game and technical prowess back then... Nowadays, with better dev tools and all that, it's not that impressive technically... still an awesome game though!

Because of the scroller, it will actually take 159 x (40+48) = +-14KB if you want to scroll infinitely. Then you have to double buffer that because sprite sorting is not going to help with flickering... so 28KB, still doable. I'm going to try some real sprites instead of snow ?, (my goal is still to test mode4) so yeah perhaps someone will take over after that and turn it into a proper game. I checked out what good looking shooters are available on A8... it's pretty much Dropzone... a shame really.

Thanks! C64 sprites are 21*24 3 cols right? 25fps on an A8 is a little depressing... Not only is char mode slower to setup, but even fast restore is debatable, since you have to save 8 more lines most of time just for vertical alignment. I wouldn't rule out char mode completely, there are things that are impossible in bitmap mode (like a parallax scroller with overlapping zones, ie R-Type). But the savings it seems to give you for frame buffer memory it takes back by requiring sprite preshifting. Depends on your use case I guess...

José kindly provided a cleaned up GF2, so here's a new version! Also: -More DLIs for more colors changes and more parallaxes (9 vs 5 in the original) -wide playfield -sprite test (30 tiny 1x1 white pixels) Could anyone test in on a real machine and let me know if it works ? I'm having an issue with WSYNC and setting HSCROL: I have to have NOPs between the 2 otherwise the display goes mad in Altirra... is that expected ? Juste a note regarding perf of sprites in mode4... it's not very good ? The code's not optimized at all but it would be at best a close call to have the same amount of sprites as the C64, the code to set the sprite drawing up is slower than the actual drawing. My gut feeling tells me it may be as fast in bitmap mode. subh_190805.zip

Well I'm doing tests with Antic4 and I figured I could use some nice graphics so I gave it a shot. It's just the parallax effect, there aren't any sprites even though it looks like there are some. I'm just using the g2f that José posted 8 years ago :) I plan on adding sprites but will not turn it into a game or anything... I added the 7 gates of jambala conversion tune by Miker and I'm using dmsc' SAPR player for extra punchiness! obx+ source included subh190731.zip

The RMT player source is available from the original package http://raster.infos.cz/atari/rmt/rmt.htm , there are newer versions in the forums though. You could also look into dmsc's SAPR player. It only supports 50/60hz mono tunes but that's most of them. How to integrate that with basic, I have no idea. It uses some ZP but you can move it out except for a 2 byte pointer. It will be slightly slower but it's much faster than RMT anyway. Storage wise it requires less than 2.5KB for code+buffers (mostly buffers), and whatever tune you use which may actually be smaller than the original RMT. Yeah, it's pretty great!

Thanks again, I'm still unsure which way to go but I'll definitely investigate OS switching.

Lots of good info, Thanks! My project specs: 128KB RAM / 1x 130KB ATR (or 2x 90KB ATR?) everything compressed on disk I'd like some minimalistic loading info, I don't want a black screen and I'd rather not have an infinite looping anim. At least some form of progress bar. At first I thought xBios would be fine and cover all my needs but it seems that there are so many new storage options that it's not possible... I'm not going to consider Custom SIO code, that seems doomed to fail. I've been thinking I could do 2 versions: 1)xBios: runs on 128KB machines with real drives and some modern devices 2)RAMdisk with early OS switch, would need 256KB machines, loads/decompresses everything in extended mem. switch off OS permanently. Run. This leaves out those with 128KB machines and devices incompatibles with xBios, is that a lot of people ? Though I'm starting to warm up to the idea of doing OS switches whenever needed.If I wanted to go that road, what's involved exactly besides saving those 2 RAM regions ? Do I need to save the stack content ? Do I need to save registers (A X Y P SP) ? What about Ithe RQ vector ? I don't recall it even being set when reaching my code. NMI Vector surely ? If I restore the NMI before switching the OS back on, surely it's going to start poking into memory ? like putting shadow registers into HW registers ? or some other crazy stuff ?

I see, it's that space saving optimization... But is that really useful when you can just exomize your xex ? I'm currently testing xBios and it works fine but it seems to have a lot of features which are unexplained. xSPEED equ xBIOS+$3e6 ; STD SPEED xHSPEED equ xBIOS+$3e7 ; ULTRA SPEED I still don't understand how to set high speed mode xIRQEN equ xBIOS+$3e8 ; User IRQ (1 byte) Does this mean my own IRQ handler will run if set to 1 ? I have no idea what it's used for... xAUDCTL equ xBIOS+$3e9 ; AUDCTL ? I wish I could remove the write to disk code with a setting in the CFG file to save some space. As for a custom IO module, I wouldn't know where to start...

No worries I thought maybe you weren't using the OS.

That's very cool... it uses SIOV though. Fair enough for the boot sector but what if I want to load files without the OS ? I've been trying to avoid using the OS because of the memory cost but I initially thought that switching off the OS then switching it back on would result in losing the content of last 16K of RAM, but it seems that its just a bank switch and it's still there if you switch it off again? If I wanted to use the OS, I'm guessing I would still need to restore a lot of the ZP, make sure the DCB area is usable, and probably restore interrupts handlers/NMI ? Not really a fan of the idea... but perhaps It's less messy thant it seems ? What about using custom SIOV routines in conjunction with your code ? It seems some are available like in Thor's OS++ ? or Altirra OS (although I'm not sure if the code is available) ? also I found one on AA I'm guessing I would lose SIO patching and it wouldn't work on modern devices ?

Is the source available ?

Well I can't edit my post after an hour (perhaps that could be extended a bit?) Just realized a load in 2 chunks would still go beyond the FinalBuffer but a big chunk of the file could still be loaded at once, moved, then the remaining sectors could be loaded in the IO buffer and copied slowly... I'm going to guess the filesize isn't even stored on the disk, so the method wouldn't work anyway?

130 cycles/byte... ? Just wondering if it could be fixed like this, not requiring too much extra space(just for the extra code)? if SA is sector alignment required to load in mem, I assume it's 128 or 256, or some power of two -load file 1st sector in IO buffer -load rest of file sectors (minus the last one) to (FinalBuffer+SA-1)&~SA -move all the bytes to FinalBuffer+SA -copy 1st sector to FinalBuffer -load last sector into IO buffer -copy last sector to FinalBuffer+FileSize-SectorSize I just realized that there would be a problem because dmsc mentioned that the last 3 bytes of the sector are actually the next sector link but perhaps the main load could be split in 2 and the memory move could move the 128 bytes - the 3 bytes of each sector. or is that complete bullshit ?

Well xboot loads fast but it still loads a a file (xbios.com) so it still has to interpret the dos file format since I guess it can't make assumptions about where xbios.com resides on the disk. But I would guess that like you said, it still loads at a fixed address so it doesn't have to copy between each sector load.

I realize that neither of you is the author of xbios but I still don't understand why the boot loader seems to load faster, perhaps it is using the OS to do the initial xboot.com load (2KB of which I don't know how many bytes get actually loaded) ? in which case does it mean the OS supports burst IO or it has a more efficient loading routine ? I may be asking dumb questions here but If it's a problem of loading consecutive sectors, is it possible to arrange the sectors in a way that suits the loader ? Or perhaps a double buffer would help ?

Thanks, I found it in the Altirra manual too, first page of the disk drive chapter... I was confused because disk2Atr doesn't have an option for 130KB disks, I found that I needed to set the sector count for that. I was going for a 130KB disk but if I want maximum compatibility I should stick to 90KB ? Are the many people using those 3rd party drives that don't support medium density ? Are ATRs usable with modern devices? Weird, I just tested the same Xbios code on a SD & DD disk (loading about 25KB) and the DD disk took at least 5 more seconds to load in Altirra.

I finally got around trying XBios 4.3 It's a little easier than I thought but I still hit a few hurdles. 1) I tried playing a tune after loading, and it wasn't playing properly (some missing channels). I guess it's because Pokey is used for loading. quick look in the Altirra man Hmm... no idea! So after loading and before playing the tune, I just did: lda #0 sta SKCTL ...and lost all channels Tried: lda #%00000011 sta SKCTL ; ... and sound plays fine. Is this ok ? 2) I'm getting the same speed issue with accurate timing in Altirra. Xboot loads Xbios.com at regular speed then as soon as Xbios.com takes over (loading my XAUTORUN). it slows down. Not sure why Xboot loads faster, I'm guessing the code is the same ? Side questions: I'm creating ATRs with disk2Atr (I think...). It creates single density disks (90KB) and double density one (180KB). Does that work on a real 1050 ? I thought disks were 127KB max ? Also DD disks load much slower than SD ones. Is that right ? 3) Xbios doesn't use the ZP but I caught something weird when I set Read breakpoints on the ZP (in my code, after setting the default device and trying to load a file) : 0E94: D0 F7 BNE $0E8D 0E96: AD FB 0E LDA $0EFB 0E99: 20 B7 0E JSR $0EB7 ;[expand] 0E9C: A9 08 LDA #$08 0E9E: 2D 0E D2 L0E9E AND IRQST 0EA1: D0 FB BNE $0E9E 0EA3: A9 13 LDA #$13 0EA5: 8D 0F D2 STA SKCTL 0EA8: 8D 0A D2 STA SKRES 0EAB: A9 20 LDA #$20 0EAD: 2C A9 00 BIT $00A9 0EB0: 0D E8 0E L0EB0 ORA $0EE8 0EB3: 8D 0E D2 STA IRQEN 0EB6: 60 RTS ;-------------------------------------------------- 0EB7: 8D 0D D2 L0EB7 STA SEROUT 0EBA: 20 CB 0E JSR $0ECB ;[expand] 0EBD: A9 10 LDA #$10 0EBF: 2D 0E D2 L0EBF AND IRQST 4) Would it be possible to create a smaller version which doesn't have any command for writing to disk ? Thanks

Is it possible to get a full example of this because this is a little confusing? What is $7ff ? is it the end of the IO Buffer ? ( .byte >$0700 ; xB buffer adress for relocator in the .cfg file ) Thanks

? That doesn't seem right? that would make .align really painful to use... Thanks for the alternative!

Ah Thanks, I actually did .align $100,$ff and that did the same thing. OPT F+ is the better solution because I'm sure I've got a few other .align scattered. (the listing is still inaccurate though)

I'm using the .align directive which works fine usually but not in this particular case: As you can see the directive is at A28C and the string "does not align" should be at A300 like it says in the generated listing file. However looking at it in the debugger, that's not the case: the directive just gets ignored. I've even tried ORG which doesn't work either (works fine too usually) using 2.0.8 b31 (switches in the pic)

Thanks for all the improvements on the debugging side! On to a completely different topic: Interlace I think I read somewhere in the forums that the A8 is capable of doing interlace (480i) but apart from that mode, should there be an interlace option at all ? When I enable it, it's really atrocious when anything moves fast horizontally and as far as I know interlace is only for displaying 480 lines I know very little about TV standards and electronics but I read a long time ago in the SNES manual (old one, not the one found online which has explanations on custom chips) how the console worked when using 240/480 lines: -Refresh is always 60HZ in 240 and 480. The difference is that in 480 lines the electron beam is offset by HALF a scanline on odd frames. Nevermind, I found the manual and the beam is offset by a full scanline. So the bottom line is: in low res don't enable interlace...duh.