Jump to content
IGNORED

Load Data from disk in Assembly


Recommended Posts

What value are you holding for $BFFD ? The OS will not be initialised only if you set bit 7.

 

Typically a value of '4' (bit 2) is used to let the cart init & start but other combinations (0, 1, 4, 5) are legitimate.

 

By 'some' memory, you'll need to clarify a bit as $300 to $30B are the resident Device Control Block (DCB) addresses and there will be some zeropage usage for sure.

Link to comment
Share on other sites

What value are you holding for $BFFD ? The OS will not be initialised only if you set bit 7.

 

Typically a value of '4' (bit 2) is used to let the cart init & start but other combinations (0, 1, 4, 5) are legitimate.

 

By 'some' memory, you'll need to clarify a bit as $300 to $30B are the resident Device Control Block (DCB) addresses and there will be some zeropage usage for sure.

A value of 4, since the initial design of the game did not require anything from the OS, it turns it off and uses the RAM under the OS area.

Link to comment
Share on other sites

Could the settings for IRQEN, SKCTL, PACTL, and PBCTL be an issue? IRQEN is just set up to read the keyboard.

 

I am going to go work on some other parts of my game and come back to figuring out this Save to disk thing. I do not want to scrap the ideal because saving game progress is a nice feature to have.

Edited by peteym5
Link to comment
Share on other sites

  • 2 weeks later...

Does this XBios thing use legal opcodes? Will it run on our MANY upgrades?

 

Lance will lose lots of sales...

 

:(

 

The XBIOS source code is freely available. You can look for yourself for illegal (undocumented) opcodes. I never found them very useful and always assemble programs without them. Using illegal opcodes would generate error messages while trying to build the binary in MADS Assembler.

 

ah. I forgot the 3x 65816 boards... (hides and runs...)

I tested some games with 65816 CPU in the emulator, they seem to play the same. One thing I do notice is when calling DLI at bottom of the display list to erase the player/missile graphics, the process is done much faster and where sprites get cut off right at the last display list line. The process is geared toward a 6502c running at 1.79 mhz.

 

 

Right now I am looking at doing this disk access directly through the OS or with the XBIOS. I am experimenting with both processes. It is something extra I am looking into and if I can get it to work great. If not, I won't use it. I think I am having problems because the game is designed with most of the IRQs and being shut off except for reading keyboard/break key. Have to look to see what hardware registers need to be set to allow disk access.

 

 

I think I found the issue with XBIOS. The source does not have that little routine loaded at $03C0, that sets a few parameters and calls SIOV in the OS. Very important. You have to keep in mind when cartridge is booted. Nothing is loaded from the OS and all RAM is available for the software on the cartridge to do whatever it needs to do with it. Can totally use all of page 0, stack, and from $0200 to $FFFF except the chip IO and area mapped for the cartridge ROM itself.

Edited by peteym5
  • Like 1
Link to comment
Share on other sites

re: illegals

 

again. it will give you some benefits in edge cases. sure you can live without them. why are A8 guys so "against"? on c64/2600 and z80 land illegals are "standard" commands. so when you are used to it like with LDA STA etc then you simply use it.

 

A8 has same CPU over complete lifetime... 400/800/XL/XE/gaming/5200.... I dont see any "evilness" in them.

 

65C02 and 65816 were not "standard" or wide spread to be honest. and still are not. but that's my opinion on them.

  • Like 1
Link to comment
Share on other sites

I think I found the issue with XBIOS. The source does not have that little routine loaded at $03C0, that sets a few parameters and calls SIOV in the OS.

 

after:

jsr xBIOS_SET_DEFAULT_DEVICE

 

you do not need it.

 

wait a moment when I publish a new game, where there will be an example of using xBIOS that will be included directly into the code and not as a separate library

Link to comment
Share on other sites

re: illegals

 

again. it will give you some benefits in edge cases. sure you can live without them. why are A8 guys so "against"? on c64/2600 and z80 land illegals are "standard" commands. so when you are used to it like with LDA STA etc then you simply use it.

 

A8 has same CPU over complete lifetime... 400/800/XL/XE/gaming/5200.... I dont see any "evilness" in them.

 

65C02 and 65816 were not "standard" or wide spread to be honest. and still are not. but that's my opinion on them.

I build most of the games around stock hardware of the Atari computer. 6502c with 16K RAM, some require 64K RAM. None take advantage of RAM over 64K. If someone puts in an alternate CPU, IO chips, or builds another costume circuit that is not standard and that has issues running my games, it is their fault. I avoid using "illegals" just in case someone plays the game on an Atari with an alternate 6502. I am debating if I should have something to check for faster CPU speeds and adjust to keep game looking normal at the bottom of the screen. Is there anyway to detect 65816?

  • Like 1
Link to comment
Share on other sites

Call_SIO_Device
            CLI
            STX DCOMND
            LDA #$80
            CPX #$50
            BEQ L001
            LSR @
L001            
            STA DSTATS
            STA DSTATS
            LDA xDEVICE
            STA DDEVIC
            AND #$0F
            STA DUNIT
            LDA xDAUX2
            STA DAUX2
            LDA xDAUX1
            STA DAUX1
            JSR SIOV
            TYA
            ASL @
            RTS

 

This is what was missing to make XBIOS work. Now I need to go through and see what I need to do with page 0 so I can make the OS read/write to disk. Right now, I am having an issue with it is getting stuck in a loop waiting for STATUS to none 0 value. Is this something that happens in a VBI?
Edited by peteym5
Link to comment
Share on other sites

MADS archive in example folder should be a detect 65816 routine.

 

have a look.

 

but imho if you are going down that route... you end up like Amiga coders... OCS, ECS, AGA, 020, 030, 060 with FPU without FPU, grafics card etc... ;)

 

There's no need to worry about the speed or CPU type providing no illegal opcodes are used. It's easy enough to make everything run at a constant speed regardless (WSYNC, VCOUNT, VBI, Timer IRQs, etc). Many well-written titles appear to have no issues even when running on a 20MHz 65C816. Relying on 6502 cycle counts is guaranteed to cause breakage, although in some exceptional cases this is probably unavoidable.

  • Like 1
Link to comment
Share on other sites

If you look at the code in Post #40, it is updated. I added :

LDA xDEVICE

STA DDEVIC
AND #$0F
STA DUNIT
There seems to be a bunch of stuff that is missing. Have to remember, cartridge software would had wiped Page 0,2,3 clean and some memory locations would need to be reset to access the disk drive

 

 

 

There's no need to worry about the speed or CPU type providing no illegal opcodes are used. It's easy enough to make everything run at a constant speed regardless (WSYNC, VCOUNT, VBI, Timer IRQs, etc). Many well-written titles appear to have no issues even when running on a 20MHz 65C816. Relying on 6502 cycle counts is guaranteed to cause breakage, although in some exceptional cases this is probably unavoidable.

 

 

The Player multiplexer DLIs have no WSYNC in them because they just set HPOSP#, SIZEP#, and COLPM# and usually does not need to sync with the horizontal line. Usually not an issue at 1.79 mhz, because the CPU are loaded before writing to any Antic/GTIA registers and the beam has moved passed the right side of the screen. But at higher speeds, the beam may be still one line up on part of the line, so some pixels may flicker on occasion.
The other issue at the bottom is sprites may not extend below as far below the playfield for overscan effects because the last DLI calls for erase before redrawing new sprites.

 

Link to comment
Share on other sites

The Player multiplexer DLIs have no WSYNC in them because they just set HPOSP#, SIZEP#, and COLPM# and usually does not need to sync with the horizontal line. Usually not an issue at 1.79 mhz, because the CPU are loaded before writing to any Antic/GTIA registers and the beam has moved passed the right side of the screen. But at higher speeds, the beam may be still one line up on part of the line, so some pixels may flicker on occasion.

 

The other issue at the bottom is sprites may not extend below as far below the playfield for overscan effects because the last DLI calls for erase before redrawing new sprites.

This illustrates my point exactly. You are relying on the properties of the CPU frequency to govern the timing of graphical effects. The simple expedient of syncing with the current scanline will likely allow your display to work perfectly well regardless of CPU frequency. Taking these steps during the initial coding phase saves the effort of retroactively fixing things later on.

  • Like 2
Link to comment
Share on other sites

I have it accessing the disk drive, emulator reports sector 361 pop up, but immediate exits. Reads 0 bytes from the file I am attempting to load. I have to check if DBYTLO and DBYTHI is being set.

I am putting the XBIOS version of the disk access program together first because I prefer something that works with filenames. I have not experimented with that other set of routines that load and saves directly to disk sectors yet.

Link to comment
Share on other sites

 

Some 'Page Read/Write' code courtesy of Infocom :)

DUNIT	= $0301
DCOMND	= $0302
DSTATS	= $0303
DBUFLO	= $0304
DBUFHI	= $0305
DTIMLO	= $0306
DTIMHI	= $0306
DBYTLO	= $0308
DBYTHI	= $0309
DAUX1	= $030A
DAUX2	= $030B

DSKINV	= $E453

	.zeropage
BlockNum:       .res 2
SectorNum:      .res 2
	
	.data
	.export CurrentDrive
CurrentDrive:	.BYTE 1

	.code

; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B	R O U T	I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
	.export WriteBufToNextBlock
WriteBufToNextBlock:
		LDA	#0
		STA	ptr1
		LDA	#4
		STA	ptr1+1
; End of function WriteBufToNextBlock

; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B	R O U T	I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦

	.export NextBlockW
NextBlockW:
		INC	BlockNum
		BNE	WriteBlock
		INC	BlockNum+1
	.export WriteBlock
WriteBlock:
		LDA	#$57
		JMP	loc_0_2023
; End of function NextBlockW

; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B	R O U T	I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
	.export ReadNextBlockToBuf
ReadNextBlockToBuf:
		LDA	#0
		STA	ptr1
		LDA	#4
		STA	ptr1+1
; End of function ReadNextBlockToBuf

; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B	R O U T	I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦

	.export NextBlockR
NextBlockR:
		INC	BlockNum
		BNE	ReadBlock
		INC	BlockNum+1
; End of function NextBlockR

; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B	R O U T	I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦

	.export ReadBlock
ReadBlock:
		LDA	#$52
loc_0_2023:
		STA	DCOMND
		LDA	ptr1
		STA	DBUFLO
		LDA	ptr1+1
		STA	DBUFHI
		LDA	CurrentDrive
		STA	DUNIT
		CLC	
		LDA	BlockNum
		ADC	BlockNum
		STA	SectorNum
		LDA	BlockNum+1
		ADC	BlockNum+1
		STA	SectorNum+1
		CLC	
		LDA	SectorNum
		ADC	FirstDataSectorLo
		STA	SectorNum
		LDA	SectorNum+1
		ADC	FirstDataSectorHi
		STA	SectorNum+1
		JSR	GetSectorData
		BPL	DoNext128Bytes
		RTS	
; ---------------------------------------------------------------------------
DoNext128Bytes:
		INC	SectorNum
		BNE	loc_0_205C
		INC	SectorNum+1
loc_0_205C:
		CLC	
		LDA	#$80
		ADC	ptr1
		STA	DBUFLO
		LDA	#0
		ADC	ptr1+1
		STA	DBUFHI
; End of function ReadBlock

; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B	R O U T	I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦

GetSectorData:
		LDA	SectorNum
		STA	DAUX1
		LDA	SectorNum+1
		STA	DAUX2
		JMP	DSKINV
; End of function GetSectorData

; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B	R O U T	I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
	.export ReadDiskBlock
ReadDiskBlock:
		JSR	ReadBlock
		BMI	DiskError
		RTS	
; End of function ReadDiskBlock

; ---------------------------------------------------------------------------
DiskError:
		; ... do what you want here

I got this to work! I figured out it only loaded one sector at a time and need to add a loop + increment the memory pointers, but it saves and loads directly to sectors. To save game progress, have to tell the end users they need to put in a formatted single density disk used just for the game saves. Have not done any tests yet on double density disks. What I have set up is GAME SAVE BLOCKS numbered 0 to 9. When it comes time to access the disk, the user just selects 0-9 on the keyboard and the program just saves or restores the game data. That way no one needs to worry about mistyping a filename. It is even error trapped so if no disk is no, or drive is disconnected or turned off, it reports disk error and lets you fix the set up.

I am however going to wait for XXL to complete his XBIOS just in case I want to have the users save to name files and it may work on any density. Not sure if it will work with SD drives or hard disk set ups because those need special attachments and DOS loaded up. Probably will not work well with a cartridge attached.

Edited by peteym5
Link to comment
Share on other sites

With using disk sector numbers to directly save or restore game status, it will not show the disk directory if DOS is used to attempt to read it, The OS routines seem to be limited to single or enhanced density. Since I made the slots 4K each, a single density disk can hold 22 save states. I created a simple indexing system that just uses a single letter, A-Z. Single density will successfully save A to V, Enhanced A to Z. Has error checking that reports "DISK ERROR" but is not specific. Reports if no disk is present, not formatted, drive is off, or tried to access SAVE STATES, W to Z on a single density disk. I tried to make it as idiot proof as possible.

 

Most likely people probably use 1 or 2 save states anyway. So if I release the game with the OS sector access routines, it will support single or 1050 enhanced density only.

Edited by peteym5
  • Like 1
Link to comment
Share on other sites

Well done so far

 

Typically a save disk such as this is something that is formatted (blanked) but not setup for any DOS, so it would make no sense for someone to try and access it from DOS.

 

I'd suggest you stick to 20 slots as not using the space on an enhanced formatted disk is no big deal. Many titles seem to be happy with 8 or 10 though.

Do you offer an option to format the disk, that could default to single density?

You can, before awaiting the user's selection of A-Z, attempt a read of a higher sector, e.g. 800, and if that doesn't exist then change the Z to V.

Link to comment
Share on other sites

Well done so far

 

Typically a save disk such as this is something that is formatted (blanked) but not setup for any DOS, so it would make no sense for someone to try and access it from DOS.

 

I'd suggest you stick to 20 slots as not using the space on an enhanced formatted disk is no big deal. Many titles seem to be happy with 8 or 10 though.

Do you offer an option to format the disk, that could default to single density?

You can, before awaiting the user's selection of A-Z, attempt a read of a higher sector, e.g. 800, and if that doesn't exist then change the Z to V.

 

I did something similar, but I later figured out I did not need the blocks to be 4K, the game saves were just over 2K, so I made them smaller, so all blocks can fit onto a single density disk. Officially the screen will state A to Z to save to slots 0 to 25. However 0-9 and some symbols will save to disk blocks beyond 26. but if single density, you can only save if the block ends before sector 720. 26 blocks is more than what anybody will use anyway. It is probably easier just to use a formatted single or enhanced density disk specifically for game saves.

 

I have not decided if I am going to wait and see if XXL gets XBIOS to work. It will be nice to see a directory and files. However, the problem is it cannot create new files, and they need to be set up in DOS ahead of time. Not everyone will know how to do this and I anticipate a big firestorm on an AtariAge thread about people having technical issues. However if XXL gets his game with XBIOS to work, I will look at it and maybe I can use it and others can use it for their programs as well.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...