Disease-themed games

[Disease-themed games]

Film tie-in Fantastic Voyage

[11 New Atari Homebrew games!]

21 hours ago, 0078265317 said:

including these 11

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

[Mad Pascal]

12 hours ago, stepho said:

n = rndp | (1<<7)

 

Thankfully compilers are intelligent enough to pre-calc the constant math, even without the optimiser enabled

    lda     $D20A
    ora     #$80

 

[Does the Atari 800 play Atari 5200 games just like an 800 game?]

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. 

[Looking for 16k games]

51 minutes ago, Wrathchild said:

I'll work out what these should be and post a patched version

Fingers crossed that this does it

CaptureTheFlag.rom

[Looking for 16k games]

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

 

[Looking for 16k games]

Here are titles that I reworked to run in 16K from cartridge

ctf.rom RainbowWalker.rom JetBootJack.rom

[Looking for 16k games]

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.

[Looking for 16k games]

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.  

[Simplest Atari 800 "boot" code?]

The source is referencing POKEY and PIA when in the first post you said these were missing?

 

38 minutes ago, atariry said:

VBWAIT: lda ANTICrVCOUNT ;WAIT FOR NEXT VBLANK BEFORE MESSING

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

 

[Major Blink - 5200 Version (32KB)]

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

[Tips For Driving Games [curves, books on theory]?]

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.

 

 

 

 

[Gosub vs JSR - Basic vs Assembler]

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.

[Gosub vs JSR - Basic vs Assembler]

9 hours ago, Eyvind Bernhardsen said:

You have to use the indirect mode. I think it’s “JSR (X)”, but it’s been a long time since I wrote any 6502 assembly. 

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

 

[Simplest Atari 800 "boot" code?]

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.

[Star League Baseball XEGS cartridge.]

On 2/27/2020 at 9:47 PM, Wrathchild said:

As GatHG loads at $900 and SLB at $500 is presume the AVGCart bootstrap is running in that area and hence being trashed.

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

[Half number decimals Atari assembler]

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.

 

[Angry Betty, new game]

On 3/1/2020 at 6:31 PM, MrFish said:

Man, is she ugly too; look at the neck on that thing... eeeeww...

 

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

[AVGCART]

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

[AVGCART]

 

5 minutes ago, jamm said:

 flashjazzcat is going to have quite a challenge improving on that

 

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?

 

[Mad Pascal]

@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  

[Mad Pascal]

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?

[FastBasic 4.3 - With DLI!]

20 hours ago, dmsc said:

One question: ¿should VBI vector the immediate or the deferred VBI?

 

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.

[FastBasic 4.3 - With DLI!]

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

[FastBasic 4.3 - With DLI!]

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