Alfred

Well that's good to know, but you can't assemble from disk with Mac/65 while using SpartaDos. It's always been bugged.

Interesting. The code won't assemble with Mac/65 1.01, runs out of memory. That's even using SpartaDos 2.3 with a MEMLO of $0DBE. I doubt there's a DOS with a lower MEMLO than that, so how did they get this thing to assemble ? This is going to be interesting.

Not a ca65 user, but you don't normally put macro parms in parens. What happens if you remove them ?

I went back and reread Lawrow's message where he says he's unclear on whether he holds any copyright on the ICD version of Mac/65. Given that, I don't see any reason for me not to release the source code to Mac/65 or SpartaDos for that matter. Harker doesn't care, and since Mike H is in the wind, his opinion doesn't matter. $title(MAC65/XL Cartridge © 1988 ICD Inc) $subtitle(Cartridge main bank for MAC65) $include "equate.asm" $include "tokens.asm" seg main ;================================= ; Process source line ;================================= Lawrow says just to respect the copyright notice, which on mine is still ICD, which is Tom Harker and he told me himself "Do what you want.".

I'm working on disassembling the PL65 compiler and it's got some weirdness in it that's for sure. One thing is that a lot of zero page references use the absolute address version of the instruction rather than the zero page version. So there's a lot of this: STA $0080 (8D0080) instead of STA $80 (8583) I'm just wondering what assemblers can do that ? I know EASMD does, Six Forks does, and MAC/65 most certainly does not. What assemblers will let you forward reference zero page variables before they are defined ? We're talking 1987 here, so the guy wasn't using mads or anything like that.

Geeze, $3000, that's nuts. I just threw mine in the garbage. Didn't see the point in keeping something that didn't work, had no cards and had no prospect of ever working.

Alfred Hume. That's the guy's name.

I don't remember today. His first name IIRC is Alfred, oddly enough. He would be about 75 years old now. I know I googled him a few months back so I knew it then, maybe his last name will come to me later. I know I have a bunch of handwritten notes on the asm/linker around here somewhere, not sure if his name is on them though. I only ever spoke to him once, and that's more than twenty years ago now.

I've done a little reversing of the compiler, and it seems it has at least one bad bug. Use of the builtin variables like XSAVE, PUSH etc. will fail because there is a bug in the table scanner, it's off by one. So references to STACK will work, but nothing after that should be found. The compiler code is so odd that I remain convinced that it was written itself in either PL65 or something like it. For sure it was not written in Action!, it doesn't have any of the watermarks you'd see if that was used.

Nothing wrong with your plan, but you need to keep any executing code out of the window. If you are including the Action! runtime package this pretty much means you have to compile from disk. When the compile is done, use the monitor to peek at location 14; this will tell you where the end of code is. Location $491 is where the code starts. It doesn't matter what DOS you use to write the binary file.

I guess that makes me diligent. I have everything I ever acquired for the 8 bit with two exceptions. I got rid of the 2 20MB 8" hard drives I got from Bob after they failed, and I also got rid of the two 8" floppy disk drives that I had bought off somebody. They were in a steel case about 3'x5' and ten inches high. The whole thing weighed about 60lbs not including the separate 40lb power supply. I decided that with hard drives there was just no chance I was ever going back to using these things and trashed them. Everything else I have, hardware and software, mostly packed away now, but still close to hand. Some of it's never been used, like the MPP pbi kit thingy.

I suspect when Bob says no it's because he doesn't have the stuff anymore. It's been many years since I last visited him in Rochester and CSS was long done for at that time. IIRC Bob sold the last of his BB boards to somebody else to build and most of the rest of the stuff simply got tossed. He was always rather careless about backing stuff up, and it was fortunate a couple of times I had copies of his work so that I could send it back to him when one of his ancient 8" hard drives failed. Didn't SJC get the rest of the mux boards, I don't remember now. I have about a dozen mux cards myself as well as handwritten instructions somewhere on how to build it into the mb and avoid using the cartridge slot. The shitty VIA was always an issue and eventually 6522's got hard to find and he gave up on the product. I don't know about him never thanking people. He was never anything but polite or courteous with me. I worked with him, sometimes talking on the phone for five and six hours at a time almost every day, for many years on various things. I used to have awful phone bills, and I used to say it would be cheaper to drive to talk to him than phone him. Now Wooley is a bit of a sore spot with him I have to admit, he didn't much like him. Partly it was because he thought some of Wooley's designs weren't as elegant as he thought they could have been, partly I think he thought he had been crossed by Wooley over some past deal. I know I don't have fond memories of Wooley either. I sent him some gadget I bought from Germany, some kind multi-switchable OS thingy and I sent it to Wooley to have a look at to figure out how it worked, and many months later all I got back was a box of broken pieces. Bob did live in the basement back then, since that's where all the hardware was. He had an old 800 wired up to run the phone system in the house. It was pretty nifty at the time, you could transfer calls to other phones, intercom etc. His mother was fine then, I think it was just easier to live at home than move out just to say he had moved out. I have a copy of the Puff BBS but it requires a dongle that also functions as a ring detector. There's nothing special about the BBS itself; the only clever part is the resident modem code which hides under the BASIC rom. Other than that it might as well be Forem or Oasis. I also have a Bob E-Burner. It's not the CSS version but what Bob himself used that was the precursor. I badgered him into making me one because the one I was using at the time, some orange cartridge one took ten minutes to burn a 16K EPROM, and his does a 27512 in like 40 seconds. Bob's not a very public guy, but if he thought somebody did good work he would say so to others, if only privately. He's certainly a decent guy though and somebody I am very happy to have known.

That would be easiest. Make sure anything that needs to be outside the bank window is first and compile from file rather than with a program in memory. That should put you well outside the window.

That was the first modification I ever did building your upgrade from the Byte article. Bob Puff was horrified when he saw it, said I shouldn't be allowed near a soldering iron. IIRC I used 18ga wire for everything. It worked fine though, and fixing the ramdisk driver was a good introduction to assembly language too.

It looks like you are swapping banks correctly. If it's crashing in the larger program, when the first swap occurs I would start thinking that some piece of interrupt code is missing. Also check to make sure that the runtime itself is not falling in the bank window. The fact that it crashes says something goes missing when the bank swaps, so it's just figuring out what the missing part is.

Has anything actually useful ever been written with Basic XE ? The only thing I've ever come across is Forem XE, which really wasn't much of an improvement over Forem MPP. I've never done much with Basic, assembly language has pretty much been the only thing I ever use, except for a brief fling with Action!. I'm curious if there's been anything done with Basic XE, commercial or not that actually used the features of Basic XE like the banked ram.

Have you got an email address for him, so that I can ask him about what to do with the source code to Mac/65 ?

Why would we need a new library ? The existing ones are pretty comprehensive I think. What functionality do you think we're missing ?

Don't forget when creating Action! executables to either insert: BYTE rts=[$60] as the first line of code in your program or else use a disk editor (like the ICD one) to change the init address from $02E2-3 to $02E0-1. If you don't bad things can happen under SpartaDos. Or get a patched copy of the cartridge where the run address has been corrected.

No you can't do it, because the compiler reuses many of the variables for the editor. If you were to do so, it would blow up execution of the program, most especially because of the zero page variables.

You have the first three sectors to hold your loader code. This is how I did it for my version of a Dos: ; DOS BOOT LOADER ; LAST REVISED: APRIL 16, 2003 ; ; .OUTPI ALFDOS ; ; ZERO PAGE HELPS TO KEEP CODE SMALL ; *= $43 ; SEGLEN *=*+2 CURRENT SEGMENT LENGTH SEGADR *=*+2 SEGMENT START ADDRESS LNKOFF *=*+1 LINK OFFSET CUROFF *=*+1 CURRENT DATA OFFSET HDRFLG *=*+1 ; *= $3D00 ; ; SECTOR 1 LAYOUT ; DBUF *=*+256 SECTOR BUFFER ; ; SOME FIELDS EXPORTED FOR THE XINIT/FMTDIR PROGRAMS ; ANY CHANGES TO THE S1 VARIABLES WILL REQUIRE THAT THE ; S1EQU FILE BE UPDATED FOR THE DOS ROUTINES. ; .ENTRY S1HDR,S1FREE,S1DEN,S1VLSR .ENTRY S1TSEC ; S1HDR .BYTE "A" ALFDOS FLAG (@$00) BTCNT .BYTE 3 BOOT 3 SECTORS (@$01) BTADR .WORD S1HDR LOADED HERE (@$02) BTINI .WORD XBCRET SIMPLE RTS (@$04) BCONT JMP XBCONT JUMP TO BOOT CONTINUE (@$06) S1FREE .BYTE 0,0,0 FREE SECTORS (@$09) S1DEN .BYTE 0 BOOT DENSITY (@$0C) S1VLSR .BYTE "AlfDOS " (@$0D) S1FMAP .BYTE 12,0,0 FREE SECTOR HEAD (@$15) S1UPDF .BYTE 0 (@$18) S1BFMP .BYTE 0,0,0 BOOT FILE DATA SECTOR (@$19) S1BFID .BYTE 0 BOOT FILE IDENTIFIER (@$1C) S1MAGC .BYTE 0 MAGIC # (@$1D) S1TSEC .BYTE 0,0,0 TOTAL SECTORS ON DISK (@$1E) ; ; THE BOOT PROCESS BEGINS WITH THE OS LOADING THE BOOT SECTORS ; IT LOADS BTCNT SECTORS STARTING AT ADDRESS BTADR. IN REALITY ; IT LOADS EACH SECTOR AT $0400 AND THEN MOVES IT TO THE PROPER ; ADDRESS. ; ; ONCE THE SECTORS ARE LOADED, THE OS JUST JUMPS TO BTADR+6 [bCONT]. ; IN OUR CASE WE JUMP TO XBCONT, THE BOOT CONTINUATION ROUTINE. THIS ; IS WHERE WE BINARY LOAD THE SPECIFIED FILE. ; ; ON RETURN FROM XBCONT, CY = 0 MEANS SUCCESS. ; CY = 1 IS FAILURE, AND THE OS WILL ISSUE THE "BOOT ERROR" MSG. ; ; WITH A GOOD BOOT, THE OS THEN VECTORS THROUGH DOSINI. THE OS ; INITIALIZES DOSINI WITH THE BTINI ADDRESS. IT IS THE RESPONSIBILTY ; OF THE LOADED PROGRAM TO CHANGE THIS. ; ; IN OUR CASE, THE STARTUP MODULE CHANGES DOSINI TO POINT TO THE ; RESET HANDLER TO FINISH OUR INITIALIZATION. ; ; BECAUSE THE OS DOES NOT ALLOW FOR DENSITY CHANGES, WE ARE ; LIMITED TO A 3 SECTOR BOOT, IN CASE IT'S A DOUBLE DENSITY ; DISK DRIVE. ; ; VALID ADDRESS RANGE IS : $3000-$317F ; BOOT CODE MUST FIT WITHIN THIS. ; ; ON ENTRY TO XBCONT, THE SYSTEM DCB AT $0300 IS POPULATED WITH ; THE LAST BOOT SECTOR VALUES. ; ; XBCONT LDA S1DEN IF SINGLE DENSITY BNE XBCINI SKIP ASL $0308 ELSE UPDATE TO 256 BYTE SECTOR ROL $0309 LDX #$FC DD LINK OFFSET .BYTE $2C XBCINI LDX #$7C SD/ED LINK OFFSET STX LNKOFF SET ALL FLAGS STX CUROFF LDA S1BFMP HAS A BOOT FILE BEEN SET ? ORA S1BFMP+1 ORA S1BFMP+2 BNE XBCLDR YES ; ; NO BOOT FILE HAS BEEN SET ON THIS DISK. ; ISSUE THE NO DOS ERROR MESSAGE AND HALT ; LDA #.LO.NODOSM STA $0344 LDA #.HI.NODOSM STA $0345 STA $0349 LDA #9 STA $0342 LDX #0 JSR $E456 LOCK JMP LOCK ; ; BINARY LOADER STARTS HERE ; XBCLDR LDA S1BFMP SETUP FOR INITIAL DATA LDX S1BFMP+1 SECTOR READ LDY S1BFMP+2 STA $030A STX $030B STY $030C LDA #0 STA $02E1 CLEAR RUN ADDRESS STA HDRFLG NEED $FFFF HEADER ; ; BINARY FILE HEADER IS $FF,$FF ; FOLLOWED BY START ADDRESS, END ADDRESS-1 ; XBLOAD JSR XBGET FETCH FIRST BYTE BCC XBL050 CONTINUE IF GOOD ; ; EOF REACHED. TEST THE RUN VECTOR ; XBL010 LDA $02E1 CHECK FOR A RUN ADDRESS BEQ XBCBAD ZERO MEANS NONE JMP ($02E0) VECTOR THROUGH RUN XBCBAD SEC TELL OS BOOT HAS FAILED XBCRET RTS XBRE2 JMP ($02E2) VECTOR THROUGH INIT ; XBL050 STA SEGADR SAVE POSSIBLE SEGMENT START JSR XBGET BCS XBCBAD EOF INVALID HERE STA SEGADR+1 ; ; CHECK IF IT'S THE $FF HEADER ; CMP #$FF WELL ? BNE XBL060 NO, KEEP GOING CMP SEGADR TEST AGAINST LSB BNE XBL060 KEEP LOADING DEC HDRFLG NO LONGER HAVE TO HAVE THE HEADER BMI XBLOAD FETCH TRUE HEADER XBL060 LDA HDRFLG CHECK MUST FIND BEQ XBCBAD FAILED, NO $FF START ; ; REST OF HEADER NOW ; JSR XBGET BCS XBCBAD STA SEGLEN JSR XBGET BCS XBCBAD STA SEGLEN+1 SEC CALCULATE THE SEGMENT LDA SEGLEN LENGTH NOW SBC SEGADR TAX LDA SEGLEN+1 SBC SEGADR+1 TAY INX ADJUST FOR -1 HEADER BNE XBL070 INY XBL070 STX SEGLEN STY SEGLEN+1 LDA #0 CLEAR THE INIT STA $02E3 ADDRESS ; ; BINARY LOADING CAN NOW BEGIN. FIRST THING ; IS TO TEST IF WE CAN DO BURST I/O ; XBL100 LDY CUROFF ARE WE AT A SECTOR BNDRY BNE XBL110 NO, CAN'T BURST LDA SEGLEN+1 IS THERE 256 BYTES LEFT ? BNE XBL200 YES, GO BURST XBL110 JSR XBGET FETCH THE BYTE LDY #0 STA (SEGADR),Y STORE THE DATA BYTE INY JSR XBINC UPDATE ADR & LEN LDA SEGLEN IS SEGMENT LOADED ? ORA SEGLEN+1 BNE XBL100 NO, KEEP TESTING FOR BURST LDA $02E3 DID INIT GET LOADED ? BEQ XBL120 JSR XBRE2 RUN THE INIT CODE XBL120 JMP XBLOAD LOAD NEXT SEGMENT ; ; COPY DATA WHOLE SECTOR AT A TIME ; XBL200 LDA DBUF,Y COPY DATA BYTE STA (SEGADR),Y INY CPY LNKOFF END OF DATA ? BCC XBL200 NO STY CUROFF SET CURRENT OFFSET JSR XBINC UPDATE POINTERS LDA SEGLEN+1 CAN BURST CONTINUE ? BEQ XBL110 NO, IT'S OVER JSR XBG020 FETCH NEXT DATA SECTOR LDY #0 BEQ XBL200 GO AGAIN ; ; FETCH A BYTE FROM THE DRIVE ; XBGET LDX CUROFF CHECK IF EOD CPX LNKOFF BCS XBG020 XBG010 LDA DBUF,X FETCH DATA BYTE INC CUROFF UPDATE OFFSET CLC SET GOOD CC RTS BACK TO CALLER ; ; NEED A NEW DATA SECTOR ; ENTERED HERE FROM BURST/IO ROUTINE ; XBG020 JSR XBLINK LINK TO NEXT SECTOR BNE XBG050 XBG030 SEC RETURN WITH ERROR XBG040 RTS XBG050 JSR RDSEC READ THE SECTOR BMI XBG030 RETURN IF ERROR LDX #0 RESET TO ZERO STX CUROFF BEQ XBG010 RETURN TO GET ; ; READ SECTOR - OS HAS FILLED IN MOST FIELDS ; RDSEC LDA #$40 IT'S A READ STA $0303 JMP $E459 GO DO IT ; ; UPDATE SECTOR WITH NEW LINKAGE ; XBLINK LDX LNKOFF LDY #0 XBK010 LDA DBUF+1,X STA $030A,Y INX INY CPY #3 END OF SECTOR ? BCC XBK010 ORA $030A MAKE SURE SECTOR IS VALID ORA $030B BEQ XBK020 ERROR LDX LNKOFF LDA DBUF,X CHECK THAT THE LINK IS VALID CMP S1BFID BNE XBK020 NOT VALID TXA CLEAR ZERO FLAG RTS XBK020 LDA #0 RTS ; ; UPDATE THE SEGMENT POINTERS ; XBINC TYA CLC ADC SEGADR STA SEGADR BCC XBI010 INC SEGADR+1 XBI010 STY $2B SEC LDA SEGLEN SBC $2B STA SEGLEN BCS XBI020 DEC SEGLEN+1 XBI020 RTS NODOSM .BYTE "Error: No DOS",$9B ; ; S1 = 3E00-3E7F ; S2 = 3E80-3EFF ; S3 = 3F00-3F7F ; ; BTEND MUST BE $3F7F OR LESS. ; BTEND = * [$3F77] ; ; END BOOT

My vote is no. It's a pretty small file, no reason not to just bundle everything together.

TCP is awful for real-time gaming. Drop a packet and you're into two minute retry delays and the like. UDP is the only way if you want something playable under poor connectivity situations. Or good ones for that matter.

I'm a bit skeptical that a native compiler can be produced that will fit in the memory of a stock machine. I suspect it will end up being XE-only.

It's because the XIO branches in the RTL to the BPut/BGet I think, and it uses the zero to mark it as a non-data transfer operation, iirc.