Alfred

How would I know what version ? There's no version number in the About box. Just says (c) 2017 by you.

There are a number of WaitCall modules for Pro and it's not clear what they all do. Some I can recognise the specific device like UDS or MSS, but others are a bit of a mystery. If anyone knows what device these specific suffixes specify, can you let me know. The last couple of letters for each are: 96 - ? presumably 9600 baud but why DU HS - highspeed ? For what ? NU PG PP QB 23 LN LT HALFW Also, what is the TCPIP one used for, the Lantronics devices ? There is no native TCP/IP stack for the Atari.

There appears to be a bug in the address counting, to wit: L3200 JMP ECHO L3203 JMP ECHOS L3206 JMP PRINTS L3209 JMP CRLF L320C JMP GETSTRNG L320F JMP SUSPEND L3212 JMP MIOSUSP L3215 JMP RESUME L3218 JMP MIORESUM L321B JMP OPNULOG L321E JMP CLSULOG L3224 JMP RDUSER ====>> This should be $3221 not $3224 Second quirk further on: L3254 JMP TOASCII L3257 JMP TOSTR L325A JMP ECHOB L325A JMP ECHOC =====> duplicate address L325D JMP DATESTMP

Around 1978 the highschool acquired a Compucolor II, and we were assigned physics problems that had to be done on it. Someone gave me a photocopy of the Adventure game source code in HP3000 Basic from an article in Byte. I spent a few months porting it to the Compucolor, and I would do everybody's physic's problems so I could maximize my time at the machine. I heard later they were kind of annoyed when I took the floppy disks with the game code on it with me when I left school. After that it was into IBM mainframes. Spent the nightshifts reading all the IBM manuals, learning PL/I, S/370 Assembler. So I was ready for 6502 assembler when I got an 800XL around 1985.

What you are seeing is a deliberate design decision. It allows for the redirection of procedures. For example, the manual shows how to replace the Error function. So in code you see: Proc Error(byte rc) which becomes as you see Error JMP Erro2 Error2 STA rc so you define your own proc Proc MyError(byte rc) but now you can do Error = MyError which changes Error thusly Error JMP MyError Error2 STA rc so any call to Error is redirected to your MyError procedure. The way to turn this off is to use the '*' keyword: Proc Error=*(byte rc) and now it becomes Error code starts here Note that using * also disables the storing of any passed parameters, so you must do it yourself: Proc MyError=*(byte rc) MyError STA rc Action! is a 1 pass compiler so things must be declared before they are used. By using the assignment of functions ability though you can call functions before they are defined. Proc Dummy() RETURN Proc Dosomething() Dummy() RETURN Proc TheRealProc() dowork return Proc Main Dummy=TheRealProc return I think this is all talked about in the Action! runtime manual. Also see the articles at Ken Squiggle's page https://ksquiggle.neocities.org/action/online

So it turns out it was using D3D9. Turning that off, as in going back to GDI, the display is fine. It also works if D3D11 is selected. Edit: Strangely enough, the dual Xeon machine with just a "Standard VGA Adaptor", all three modes display fine via RDT to the vm, D9, D11 and plain GDI. Bit surprised at the D11, did that even exist back in 2010 when this machine was built ?

I will try that. This is under VMWare Workstation Pro 17. The underlying processor is an Intel 8700K, so while there is no graphics card, there is some 3D support with the Intel HD graphics. I’ll have to test it on another server which is a dual Xeon box with no graphics card, and not even HD Graphics. That’s a Server 2008 Datacenter Edition machine, and it renders the VM desktops reasonably well over RDT so it must have something. I think it’s limited to 1024x768 for the console display, VGA only.

Is it expected that if running Altirra on a remote machine and viewing it through Remote Desktop the screen is just solid gray ? It looks find on my local machine but if I run it in a vm, I can hear it booting, but the screen is just plain grey, and fiddling with options changes nothing. Edit: switching to full-screen makes the screen visible, which is a good enough workaround.

Count = 0 sets the address of Count to absolute address zero, which would also be zero page zero. Since this location is unused after powerup, no crash occurs. However it means the value of Count is undetermined, it will be whatever was last deposited at 0. So if it was say 57, the DUM assignment on the first pass becomes DUM = COLTABLE(57) which probably is junk as far as colour goes. It will keep on being junk until it loops back around to zero. Action! does not initialize variables unless you tell it to do so. The fact that it always seems to be three is strictly coincidence, whatever is using $00 just happens to always leave a 3 in it when it is done. Count = [0] says to initialize Count to zero, thus the loop operates correctly.

So what does the 6502 do while the fpga is doing it's thing, just wait or loop on some status register ?

I don't understand your math here. A 6502 will not do 32 bit division or multiplication in 15 clocks, we're talking hundreds even with the use of zero page. If you're saying the 6502 only has to prep the fpga with those few instructions, well then that's not really a 6502 vs a 68000, that's custom fpga vs generic 68000. I do like the idea of a lower level language that has features to make assembler coding easier.

It's a bug. The code does the left shift and stores the result in the low byte but then it just stores zero for the second byte, rather than doing ADC #0. I think the earlier guess is right, it sees the 193 as a byte operand and for some reason thinks the output will also be a byte, which isn't true in this case.

It occurs to me that the same reasoning could apply to portb in normal mode: it keeps stuffing portb to make sure the statement bank is always present.

Must be a bad cart file, I'm not aware of any issues with Extend in either 4.1 or 4.2

I expect the answer is the cart is not differentiating between Extended and Normal and just sets PortB in case it’s in Extended mode, thereby saving some bytes by not testing some flag.

Ok, but I'm not really seeing the problem. I suppose it might be a problem in normal mode, but in Extended mode I expect the code keeps jamming PortB because it needs to make sure the correct bank is enabled to process the current statement. Or are you talking about the case where say there are more than 4 banks, like a 256KXL or something, and you can't access all those other banks ?

Why, is there something wrong with it ? It's not bugged as far as I know.

Looking at the cartridge source, it seems BLOAD was an afterthought because it's not implemented properly. As mentioned above, RUN/INIT addresses are ignored, although loaded. The XBL routine merely opens the file, checks for the $FFFF header and then just loads each segment. What the code doesn't do is handle the EOF case when it's looking for the next header. A true binary loader, if EOF is detected at this point would invoke the RUN address. Instead BASIC XE invokes IOTEST to examine the error and if it's not the BREAK key, it does nothing. XBL then sees the error and simply exits via ERRNSF which is "File not LOAD format", error code 21, which is wrong. My guess is XBL is called via the LOAD command to handle loading a BASIC program and it handles the EOF case. Someone then thought of it for loading binary files, but neglected to handle the EOF properly.

Curious, why does it implement the N: handler in C instead of using loading/using the existing assembler based version?

You need to load the Basic XE extensions in order to use procedures. I suspect error 33 is a keyword not found type of error. Make sure the BASICXE.OSS file that is the right version for 4.1 is on the disk you are using with BasicXE. Edit: Error 33 is: ERRNI INC :BR0 ;FUNCTION OR STMT NOT IMPLEMENTED

Do you have an example ? The largest variables are CARD, POINTER and INTEGER, which are all two byte values. It shouldn’t even be possible to define a three or four byte number, and none of the runtime library, like say integer multiplication, allows for anything larger than 16 bits. What were you trying to pass ?

I'm not aware that the cartridge runtime allows the passing of any parameter that is larger than two bytes. The largest value in Action! can only be two bytes, whether you use the cartridge runtime or not. I'm not sure how the toolkit FP routines deal with passing FP values or defining them.

Create a STARTUP.BAT file and put the line KEY OFF in it to disable the keyboard buffer in 3.2.

No, M: will refer to the Multiplexer device. 33a is Carden’s disassembled version of 3.2D that he updated for use with BBS Express Pro, if I recall correctly. He changed a bunch of stuff for no reason, like the S at $0700 is now R for RealDos. Unless you’re running Pro, there’s no reason to use RealDos. As for the dongle, I don’t know. In the other Puff BBS thread I think someone disassembled the MOE and posted the wiring for the dongle. I don’t know offhand how you can implement ring detection in Altirra such that it will work with the bbs. Probably have to modify the code to watch for the CONNECT string and also patch the MOE to remove the dongle check.

I should clarify, I ran it under 3.2D, I have no idea if it works under SDX.