Wrathchild

Film tie-in Fantastic Voyage

Only one of those 11 were for the 5200 I thought?

Thankfully compilers are intelligent enough to pre-calc the constant math, even without the optimiser enabled lda $D20A ora #$80

As Rybags says, those would be conversions. In the 5200 two of the custom chips are at different memory locations, the cartridge startup detection is different to that of the A800. There is no way the 5200 binary will run on an 800.

Fingers crossed that this does it CaptureTheFlag.rom

Thanks for the report, its part of the copy protection that needs values adjusting due to the relocation. I did that for the 5200 version but not the A8 cart. I'll work out what these should be and post a patched version

Here are titles that I reworked to run in 16K from cartridge ctf.rom RainbowWalker.rom JetBootJack.rom

Depends what image they are using. With an UNO/AVG/Ultimate style cart that can CAR/ROM images then running a title that runs in 16K or less is fine. If it is an XEX version of a ROM then that cannot load to RAM and then relocate to the ROM area as there is no RAM there. Some 8K games can be relocated to have their code in the top 8K of the 16K of RAM and then run in the lower 8K. ATR images are generally out the the question as a mod'd OS is loaded in the area under the OS which again is not RAM on a 16K machine. [Edit] Additionally the UNO/AVG type carts use their own XEX loader code copied into RAM (typically at $700). That can conflict with the XEXs trying to be loaded as tape games would typically load from $480/$500/$600. So a way around that is to use a compression tool (e.g. exomizer) to create a self-extracting version from this that loads at, say, $900. Sometimes 16K versions of games are patched as XEXs but now need more that 16K to load, again compression would get around that.

Our first Atari was a 600XL with 16K so fond memories of tape games played on top of some mentioned already: TT Racer, Match Racer, Baja Buggies, Alien Swarm, Encounter! (came with both 16K and 32K versions), Ghost Encounters / Action Quest, Sea Dragon, Stratos, Attack at EP-CYG-4, Galactic Chase, Canyon Climber, O'Riley's Mine, Zaxxon, Shooting Arcade Plus there are the Brian Howarth and Scott Adams 16K tape versions of their adventures. Some needed the OS/B translator but you should be able to find patched versions online. Go for the tape versions as often the disk versions needed more memory, but you can find then as XEX versions rather than CAS and run from an SIO2xx device. Or make a compilation of them on an AtariMax multicart.

The source is referencing POKEY and PIA when in the first post you said these were missing? This seems odd as there is no actual check going on here? What should be going on here is that only middle (RESET) vector goes to PWRUP. The IRQ handler might not have much purpose in a simple design and so could be handled with: IRQ_BRK: CLD JMP (VIMIRQ) DUMMY_IRQ: RTI INIT_IRQ: LDA #<DUMMY_IRQ STA VIMIRQ LDA #>DUMMY_IRQ STA VIMIRQ+1 RTS The NMI handler should be able to handle display related interrupts and so this would include the vblank and dlisplay list interrupt: NMI_handler: BIT NMIRES BPL not_dli JMP (VDSLST) not_dli: CLD PHA TXA PHA TYA PHA STA NMIRES JMP (VVBLKI) This would therefore need so basic functionality associated with it, e.g. copying shadow registers to h/w registers INIT_NMI: LDA #<DLI_Dummy STA VDSLST LDA #>DLI_Dummy STA VDSLST+1 LDA #<VBI_handler STA VVBLKI LDA #>VBI_handler STA VVBLKI+1 RTS DLI_Dummy: RTI VBI_handler: LDA SDLSTL STA DLISTL LDA SDLSTH STA DLISTH LDA COLOR0 STA COLPF0 LDA COLOR1 STA COLPF1 LDA COLOR2 STA COLPF2 LDA COLOR3 STA COLPF3 LDA COLOR4 STA COLBK LDA SKSTAT AND #SKSTAT_LASTKEY_PRESSED BNE KB LDA KBCODE CMP CH1 BEQ KB STA CH KB: STA CH1 PLA TAY PLA TAX PLA RTI In your startup code you can add calls to INIT_IRQ and INIT_NMI

Scrolling message at the bottom of the title page says "Berks Four" ?

I wouldn't say its been done to death already but there has been a fair degree of discussion. So I'd concur with the javascript link that @popmilo posted is a good read.

There is also an advantage of the 2nd (indirect) option as this can be used direct from ROM (cartridge) code where the 'target' is then stored in the RAM area and so can be modified. With the 1st version the trampoline JMP cannot be located in ROM as any store to the target address has no affect. Therefore those 3 bytes would instead have to be relocated to RAM and assembled with a different run address so that calls to it resolved to the relocated address.

Close, you'd ned to use a JSR to a JMP CallFunc: .byte $4C ; JMP abs FuncAddr: .word 0 ... .macro SetFuncAddr addr LDA #<(:addr) STA FuncAddr LDA #>(:addr) STA FuncAddr+1 .endm ... ThisAndThat: SetFuncAddr DoThis JSR CallFunc SetFuncAddr DoThat JSR CallFunc JMP ThisAndThat DoThis: LDA #0 STA COLOR3 RTS DoThat: LDA #15 STA COLOR3 RTS

What you are doing sounds more closer the 5200 and so I'd suggest taking a look at its ROM routine. I presume the RAM runs from $0000->$3FFF and the ROM from $E000->$FFFF and so the ROM sets the startup/interrupt vectors in the last 6 bytes. The 5200 OS has the Atari logo page and so would be a good starting experiment. The only difference is that instead of the OS looking for the cartridge and using it's init/run vectors, your application code would be in the ROM area instead.

I have finally got around to fixing the Star League Baseball XEX by chopping 1K from the front so that it now loads at $900 and then once loaded it puts that 1K back at $500. Therefore this will run OK on a 32K machine (and hopefully now from an UNO/AVG cart) Star League Baseball (low load).xex

How do you intend to use them? A staring point would be to read about fixed-point representation But you have alternatives such as using BCD math over a number of bytes and when displaying place a dot before the final digit. Or you can use the floating point package.

This confirms you're not this Mr Fish who loved wattle

Ah, I need to catch up on fjc's YT channel

Considering the AVG stands on the shoulders of the UNO and fjc has previously given advice to tmp, I find this a bizarre comment. In what regard would he have to improve something?

@zbyti no worries POKEY's random number generator should in no way be seen as a good candidate for use in a Monte Carlo simulation

n = (rndp | 128) ^ 128 This is producing: lda $D20A ora #$80 eor #$80 is that not the same as: n = rndp & 127 either of the optimizer flags doesn't detect and replace this?

My recommendation would be VVBLKD as out-of-the-box the OS is pointing this ($224) to the Pull Y/X/A and RTI code vectored to by XITVBV. So you would hook this a call to SETVBV with A=7 and XY with the routine's address. At the end of the constructed VBI code, you would end with "JMP XITVBI". Injecting "LDA #0, STA $4F" into the VBI code might be OK to do (although does affect attract mode colours) but an alternative could be to offer a command within the VBI such as "NO_ATTRACT" which performs "LDA #0, STA $4D"? Perhaps the $224.w value can be copied to $238.w when setting up (before the SETVBV call) as Mapping states that as spare? This can then be loaded into XY and SETVBV called to restore.

I'd forgotten to mention another idea, let the user state WSYNC as in the example you are in Gr.0 and even with a DLI stated each line then you can only update registers every 8 lines. DLI SET graded_dli = $04 INTO $D017, DLI = WSYNC, $06 INTO $D017, DLI = WSYNC, $08 INTO $D017, DLI = WSYNC, $0C INTO $D017, DLI = WSYNC, $0C INTO $D017, DLI = WSYNC, $08 INTO $D017, DLI = WSYNC, $06 INTO $D017, DLI = WSYNC, $04 INTO $D017 The way you've coded things already automatically injects the WSYNC store between the LDA/STA of the first 'INTO' and so the same principle can apply to an INTO preceded with a WSYNC. This would permit multiple WSYNC entries to be used, e.g. re-writing the above: DLI SET graded_dli = $04 INTO $D017, DLI = WSYNC, $06 INTO $D017, DLI = WSYNC, $08 INTO $D017, DLI = WSYNC, $0C INTO $D017, DLI = WSYNC, WSYNC, $08 INTO $D017, DLI = WSYNC, $06 INTO $D017, DLI = WSYNC, $04 INTO $D017 resulting in something like: fb_lbl_graded_dli: .byte 72 .byte 138 .byte 72 .byte 169 .byte $04 .byte 141 .word WSYNC .byte 141 .word 53271 .byte 169 .byte $06 .byte 141 .word WSYNC .byte 141 .word 53271 .byte 169 .byte $08 .byte 141 .word WSYNC .byte 141 .word 53271 .byte 169 .byte $0C .byte 141 .word WSYNC .byte 141 .word 53271 .byte 141 .word WSYNC .byte 169 .byte $08 .byte 141 .word WSYNC .byte 141 .word 53271 .byte 169 .byte $06 .byte 141 .word WSYNC .byte 141 .word 53271 .byte 169 .byte $04 .byte 141 .word WSYNC .byte 141 .word 53271 .byte 230 .byte COLRSH .byte 104 .byte 170 .byte 104 .byte 64 [EDIT] So taking the test.bas, building it with 'fb-int' and then replacing the DLI code in the 'asm' file with that given above and then building that with: cl65 -t atari -C fastbasic.cfg -o test.xex test.asm fastbasic-int.lib gives: test.asm test.bas test.xex

I think the ideal could be something like this - as if you define the routines in reverse order then you can reference them, and the last does not need to set the first if this is done in the VBI, e.g. DLI SET dli3 = pos INTO $D000, pos INTO $D001, DLI = $CE INTO $D013 DLI SET dli2 = pos INTO $D000, pos INTO $D001, DLI = $88 INTO $D012, DLI = DLI dli3 DLI SET dli1 = pos INTO $D000, pos INTO $D001, DLI = $28 INTO $D012, $2E INTO $D013, DLI = DLI dli2 VBI SET vb1 = DLI dli1 ... VBI vb1 As an example, the VBI can then also be used to call a linked RMT player routine