.jpg.a99628c7b160d1415febaf500e711542.jpg)
Alfred
-
Posts
943 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Alfred
-
-
Change the LDX to any of $10,$20,$30,$40,$50,$60,$70. $00 is reserved for the E: device. CIO expects X to be loaded with the channel (0-7) number times 16.
-
If this is from an Amstrad why do you think these village.bin files will execute on a different machine ? I would have thought you’d have to disassemble the original game and then write all the new Atari code. Or maybe you’ve done that already ?
-
1
-
-
The dlist is wrong for one, HELLO2 needs to be converted from Atascii to video, say with an .SBYTE directive.
-
Just trying to build the sieve.pas example. MP compiles it fine, but mads has issues:
What file has the missing definitions ?
-
18 hours ago, slx said:
I learned it from Rodney Zaks’ book combined with Antic articles and De Re Atari. I am pretty sure I wasn’t clever enough to come up with that myself but copied the idea from some code I saw but don’t have the faintest idea where that might have been.
Google shows it mentioned here and a similar construct is in the SpeedScript source code.
May I ask if it’s the low/high byte notation you found strange or anything else? Come to think of it, if it’s the former it is probably due to my not checking that a pseudo-opcode to store a 2-byte value would work as well (like .WORD START or .DB START).
It was the low/high byte separation. Normally all you see is a .WORD address. to see low/high there was surprising.
-
1
-
-
Ok, so the PLA version works, but when I change the sequence back to the stack version:
; all regs 16 bit
TSX
LDA $0102,X
STA CALLER
I get $0000 in CALLER. $0100,X should be the next free stack byte, $0101,X is the PHP byte, so $0102,X ought to be the first byte of the return address. What am I missing here K, why am I not seeing $3C52 in the stack version ?
edit: NM, in changing the code up I made a mistake about the stack. Both versions work correctly now.
-
1 hour ago, drac030 said:
Does .ALLW imply/execute REP #$30 and .ALLB - SEP #$30?
If so, then you are first pushing the P register status onto the stack (PHP in the first line), then you are pulling "CALLER RETURN", but in fact you are pulling the P byte + a part of the return address with that? Then the next PLA gets the other byte of the return address instead of the P register byte. These need to be swapped, PLA-byte first to get the P register status, then PLA-word next to get the return address, no?
You're absolutely right. I figured it had to be my code but I wasn't seeing it. Thanks.
-
20 minutes ago, drac030 said:
It should be $3C52, but it is $3152. So the question is: is acc really 16-bit at $A8D3? Especially if the JSR is being done "IN NATIVE 8/8 MODE"...
It really is, I've left out the various SEP/REP and other instructions to simplify the example.
The full code is:
ABEND PHP SAVE CALLER STATE
;
.ALLW
;
; SAVE ALL REGS AS WORD SIZE
;
STA SAVEA
STX SAVEX
STY SAVEY
;
; PUT CALLER'S JSR ADDRESS INTO TERCOD.
;
; TSX X = STKREG.
; LDA $101,X LOW BYTE.
PLA PULL CALLER RETURN
STA CALLER PUT IN LSB POSITION.
;
.ALLB
;
PLA
STA PSTATUS PROCESSOR STATUS
;
PHK
PLA
STA CALLER+2 CALLER'S BANK
------------------------------------------I was getting $0303 using the stack extract, so I changed it to the PLA version and it's still wonky. I need to play with it some more to try and understand what's going on with the stack pointer.
Edit: yes, I understand the PHK isn't really the caller's bank, it just is in this case.
-
I've run into an odd quirk in 65816 mode with regards to the stack. Code is simplified here for the example.
; IN NATIVE 8/8 MODE
3C50 JSR $A809 ->> leads to A8D3 via JMP
......
; ACC IS 16 BIT HERE
A8D3 PLA
STA $A9BBA9BB $3152 ??
Should be at least $3Cxx, should it not ? This is 4.30 test6.
-
23 hours ago, slx said:
; ORG $02E2 .BYTE <START .BYTE >START
I'm curious, from what source did you learn 6502 assembly language ? In almost 50 years, I have -never- seen that construct for an init/run vector.
-
On 1/11/2024 at 5:02 AM, Wrathchild said:
Oh yes, love that it had no instructions! 😆 It probably took a couple of months overall seeing as you needed to work out who needs what and find a route where you don't run out of time, well designed game. Shame we didn't get part 2.
I still have the piece of graph paper with all the clue stuff on it. It was really quite a good game.
-
On 1/11/2022 at 1:57 PM, thorfdbg said:
This type of "copy protection" was also used by "The Eidolon", which stores its caves and graphics in a regular Dos 2 file structure, except that the directory starts in another sector. It is not too hard to decode these data files, or create your own caves if you like to.
The Eidolon also used duplicate sectors. It took me a while to relocate them and alter the boot sequence.
-
21 hours ago, Darken99 said:
Thanks. I've been using 3.2g but I'll try that next. Any particular reason for the suggestion?
Very low memlo, something like $0CBE compared to 3.2's $1C19. Extra 4K comes in handy. Can't use it with Basic XE though, as they both use the block of ram under the OS at $C000-$CFFF.
-
1
-
-
If you can find a decent boot disk, unless you are using Basic XE, I would suggest using SpartaDos 2.3.
-
1
-
-
2 hours ago, danwinslow said:
The Altirra debugger seems so much better than anything you could run from within the atari...if you have that available why would you want to use either of these native debuggers?
Agreed. Extremely capable and insanely complicated with dozens and dozens of commands.
-
12 minutes ago, MrFish said:
One heads-up for using DDT within Altirra: an alternate keystroke needs to be set for starting Extended DDT, because Windows already has <ctrl><shft><esc> set for bringing up the task manager (at least it does for Windows 7, which I'm using). So, I just set Altirra to emulate <ctrl><shft><esc> with <ctrl><shft><"`"> instead.
I seem to recall the arrow keys are messed up in Altirra, you have to hold the shift key when using the arrow keys.
-
Yes, one: Forget Bug65. DDT is far superior. I don't understand your comment about using disk versions so you can share. There is nothing about using the cartridge version that stops you from transferring files out of Altirra.
-
I was wrong, on page 20 of the Action! Runtime manual, chapter 5.2.3 it quite clearly states you must set DEVICE to zero.
-
1
-
-
Really it's just meant as a bit of coding shorthand, such that when you are dealing with the screen, you can use things like Print or PrintC instead of having to always specify the channel, like PrintD(0,string). It just saves you from having to put in 0, all over the place. Since you're mostly dealing with the screen, you set device to zero and forget about it. If you want to read a dir entry like your example, well then you have to use something like InputSD(1,dirstring). You wouldn't normally change device to 1, unless you maybe had a lot of i/o instructions and didn't feel like typing 1, all the time. Your choice. You just need to remember that whatever the operation is you are about to do, if you aren't using the "D" version and specifying the iocb #, then it will go to wherever device is pointing.
-
11 hours ago, _The Doctor__ said:
negative acknowledgement (device) vs not acknowledged(OS/software) , on some devices it can also mean rejected which is incorrect use of nack. The device itself NACKs, the OS NAKs.
NACK from a device to a receiver of the data sends a message to ensure that the requester resends the needed data.
Depending on its implementation, NACK can often serve the same purpose as other network acknowledgment solutions like REJ or ACK for things like the Network Cards/Cartridges, or even FujiNet, though I am not certain if FN implements it through SIO since REJ (reject) isn't something formally seen in our circles but is akin to Negative.
Original SIO outlined
First the computer sets the COMMAND line on the SIO line to the jack.
Then it sends the command block (4 bytes + checksum)
Then waits it waits for a response (1 byte without a checksum):
$41 (A) = Acknowledge, the command is valid and will be executed.
$4E (N) = Negative, the command is invalid.
If the device responds "N", the transfer is normally aborted.
If it responds "A" the data block is transferred with the checksum.
Now the computer waits for a final acknowledge of 1 Byte without a checksum
$43 (C) = Complete, operation completed successfully.
$45 (E) = an Error has occurred.If any of these do not respond at all a timeout will occur.
https://github.com/HiassofT/highspeed-sio
https://www.horus.com/~hias/atari/#hipatch
explains things very well and his website carries the latest greatest stables
in addition to this excellent resource, search up PCLINK driver, and look over some of the burst mode discussions.
I know you want to implement just what Atari had in mind, and the smaller the changes the better so it's all food for thought.
Right, NAK is what the OS returns if the drive response is not A\N\C\E.
-
You misunderstand. device is the default device that is used when you don’t specify a channel. It is zero by default because iocb 0 is always open for E: by default.
So in your first example, you open file B on iocb 1 and set device = 1. Now if you do a PrintB(57) the number will be sent to file B because that’s the channel to which you have set device. It’s very rare that you would change device to other than zero because most of the time you want the output to go to the screen. For the other cases, you just use the channel version of the function like PrintBD.
-
1
-
-
Just now, reifsnyderb said:
Yeah, I didn't see it either.
Nak vs Nack? Is there a difference or is that a typo? I didn't see any mention of that....or missed it.
The error codes in my copy of the OS source are different for the drive than what the OS returns. So it shows the drive returning an error of NACK whereas the OS returns the error code NAK which is a different value.
I see, you're rolling your own SIO. Well you can forget using the stock OS routines, they use interrupts. You can't do that for high speed sio, you have to switch to polling because interrupts are just way too slow. Instead of re-inventing the wheel, why not just patch in Hiasoft's code. Throw out the international character set, and the cassette handler, that's usually what everyone does to get room in the rom for their custom code. Good luck.
-
Looking at the OS SIO code, I see no evidence that is sets $0306 or $0307. NAK is the default error if the device responds with something other than ACK/NACK/ERROR.
-
NAK is an odd error, that's what you get when the drive door is open. I'm not sure about DTIMLO getting set by the OS, I think Mapping is thinking of the DSKINV call at $E453, which does do some stuff, but you should be calling SIO directly at $E459 for this command. Might as well try it, set DTIMLO to something, 5 or whatever, and $0307 to zero, and if that doesn't work, then it's probably a config issue in Altirra.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Six Forks Assembler Upgrades
in Atari 5200 / 8-bit Programming
Posted
Updated disk. SFA8 and SFL8 may just be copies of SFAXE8 and SFLXE8. I ran into bugs with my copy, so made new ones, but it's not clear if these old diskette ones are still good.
SFAX816 is the current 65816 version, only requires a machine with XE-style ram banks, not an actual 65816. Allows for eight character labels, 384 labels per assembly. If any segment is assigned an address above the 64K boundary, the linker will produce a binary that has a non-standard header, starting with $FCFC. See the pdf for more details, I updated some things, new directives etc. Alternating my time between this and my 65816 DOS.
CURRENTSIXF.ATR NewSixf.pdf