Roydea6 Posted February 27, 2012 Share Posted February 27, 2012 If your just looking into this for compatibility for you hardware. Have you check out Basic XL and Basic XE?? Does Atari Basic 'C' work OK on you hardware? How about the other languages Assembler....etc.? Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 27, 2012 Author Share Posted February 27, 2012 This is the only known bug on the hardware. (at the moment) All other languages run OK. ASM/ED, BASIC 'A' and BASIC 'C' are OK as internal carts and real carts. I assembled the MyDOS 4.5 files with MAC65 on the machine. OMNIMON and US+ OS run OK. DOS 2.0, 2.5 and MyDOS run OK, with this one exception with MyDOS. The system uses a 65816 with battery-backed SRAM. Some 65816 software does not run, but I would guess that to be expected. All of the code is in upper linear memory, including the internal cart, OS and PBI code. From the CPU, it is read-only unless you boot in 1200XL mode, which disables all the SRAM based data and runs from the regular 1200XL ROMs. The PBI allows for two IDE/CF interfaces (not master/slave) and runs generic routines in $D800-$DFFF. Drive configuration is kept in $D6xx along with a little code that allows dynamic 'disk' selection with the Fx keys. Any and all of the IDE 'drives' can be disabled if you want to run SIO. Doesn't matter if you run 4.50 and TBXL from the CF card or SIO - both fail the same. The major issues are normally 65816 based, rather than code. I use Sweet16 modules to test applications for 65816 collisions. The Sweet16 doesn't add anything other than the new CPU - runs OK with MyDOS 4.50 and TBXL. MyDOS 4.50 and TBXL do not run in 1200XL mode on a WIDE, which indicates a hardware glitch somewhere in the CPLD. We get the wrong answer somewhere. Need to fix that. If we don't, who knows what kind of nasty things will show up if people start using this? Bob Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 27, 2012 Author Share Posted February 27, 2012 Well, I'm sure learning more about TBXL and MyDOS loading than I ever wanted to know... Bob Hehe, I feel this wil become the "everything you every wanted to know about 1200 XL but went wrong" thread . Quote Link to comment Share on other sites More sharing options...
+Larry Posted February 27, 2012 Share Posted February 27, 2012 For the record, Bob was absolutely right. I swapped out the Antic that was producing the screen garbage when 3.07 was loading TBXL. Another Antic from a 600XL donor gives a perfect display. -Larry Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 29, 2012 Author Share Posted February 29, 2012 Found it... The code at $1299 restores the IOCB into zero-page memory after an INIT. It loads from IOCB,X and stores into zero-page with a STA zp,Y. All well and good - except MyDOS chooses to use Y as the test for the last byte in a manner that counts upward from $FF2C,Y and then looking for Y=$00. (instead of something like STA $20,Y and test for Y=$2C) In a 65816, such code will store in the next 64K segment: $01002x, not $00002x. It does not wrap back to $0000 like the 6502 must do. Even that is not a problem on a 65816 system if you only have 64K of memory. It will generate the address bits for $01002x, but the extra bits are not implemented so the data still goes into $002x. Wide has the extra memory enabled, so it puts the data where it is told to put - in $01002x. And, when we later read $0026... we get nasty stuff and croak. Soooo... software problem! Not my job, but the code could be fixed if someone cares. Thank you all for the assistance. Bob Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 29, 2012 Share Posted February 29, 2012 Well done for figuring it out, Bob. I'm relieved you finally got to the bottom of this very mysterious issue. Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 29, 2012 Author Share Posted February 29, 2012 It's actually pretty nice how the linear memory works in the 65816. It will jump to the next segment (64K) when you are accessing memory with indexes, even in 6502 mode. Maybe we can get the hardware to switch segments while ANTIC has HALT active. Bob Quote Link to comment Share on other sites More sharing options...
+Larry Posted March 1, 2012 Share Posted March 1, 2012 Hi Bob- Even though a software issue, have you given any thought as to how (conceptually) you would approach the problem in software? Patched TBXL? Presume it is not possible to shift the WIDE to 6502 emulation mode at the start of loading and then turn the native mode back on at the end? But what about in 1200XL mode? -Larry Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 1, 2012 Share Posted March 1, 2012 Even though a software issue, have you given any thought as to how (conceptually) you would approach the problem in software? Patched TBXL? It's MyDOS which needs patching. TB is doing nothing wrong - just providing an INIT address as would any other perfectly legal executable. Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted March 1, 2012 Author Share Posted March 1, 2012 Yes, this is a MyDOS issue, although I can't be sure that is all of it without correcting the code. The CPU mode does not change between WIDE and 1200XL configurations, only the hardware code sources (OS, cart, PBI). Even in 1200XL mode, the linear memory will affect cross-segment indexing. The objective was to determine if this was a hardware/design problem in WIDE (it sure seemed to be) or some weird software. I am not qualified to fix the code and have no confidence that I would not introduce some other, nasty bugs that break someone else's code tweaks. If it were a game or such, it wouldn't carry the ability to mess up files/data that a DOS does. Bob Quote Link to comment Share on other sites More sharing options...
+JAC! Posted March 1, 2012 Share Posted March 1, 2012 (edited) Thanks for finding the issue. This was geeting too weired and I already saw myself ending up in the complete reconstruction of TBXL :-) For me this is a hardware problem. How about a hardware solution like letting the linear memory start only at $20000 and mirror the first $10000 bank (ignore bit A16). This way you achieve the same behaviour as in 6502 mode without any software modification. Edited March 1, 2012 by JAC! Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted March 1, 2012 Author Share Posted March 1, 2012 We might turn off linear memory, but crippling it would be difficult. There is only a limited amount of time for the logic to react to the high-order address bits - they have to latch 35ns after the cycle starts and it takes 30ns for the CPU to output them on the data bus. If we just ignore A16, we won't be able to cross segments at all, even when we want to. I can't make a case one way or the other as to whether this is a software or hardware 'problem', but the hardware is working the way it is designed to work. It isn't a bug. If we see more of these kind of things, maybe we can add a configuration bit for this when we re-visit the hardware code. Bob Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 1, 2012 Share Posted March 1, 2012 (edited) I think it's a software problem. The indexed addressing you describe - while it obviously works owing to a quirk of the address wraparound - looks like quite a kludge to me. Code like that feels pretty smart at the time until conditions change and it doesn't work any more and people have to spend a week figuring out why. Simplest solution is to fix up the offending code in MyDOS and tell everyone who insists on using that DOS with your hardware to upgrade. Edited March 1, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+Larry Posted March 1, 2012 Share Posted March 1, 2012 Yes, MyDos needs patching, but seems to me it should be far easier (and safer) to change TBXL (one application) than to change a Dos that might make many other things break. -Larry Even though a software issue, have you given any thought as to how (conceptually) you would approach the problem in software? Patched TBXL? It's MyDOS which needs patching. TB is doing nothing wrong - just providing an INIT address as would any other perfectly legal executable. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 1, 2012 Share Posted March 1, 2012 Yes, MyDos needs patching, but seems to me it should be far easier (and safer) to change TBXL (one application) than to change a Dos that might make many other things break. I fail to see how patching TBXL will fix this. It's using the same INIT mechanism that any other executable uses. Better to patch DOS than dozens of executables which might exhibit the same problem, surely? Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted March 1, 2012 Author Share Posted March 1, 2012 The reason TBXL fails is that it enters INIT multiple times (I think). I don't know how you could fix it other than a re-do of the loading sequence. Anyway... Here is one POSSIBLE fix for the problem. I needed more bytes so I used the 65816 instructions PHX and PLX, saving just enough code space so that a CPY #$0C can be used to control the loops. This means, of course, that it will not run on a 6502! But, it does demonstrate that the indexing mode is the problem. TBXL loads and runs in all modes on a WIDE system. The listing: I use the ASM/ED cart so the 65816 instructions have to be cocded as .BYTE $xx op codes. Assemble this directly into memory, go to DOS and Write DOS Files to disk. This will be your new, 65816-only MyDOS/TBXL disk. If our MyDOS listings are accurate, this will not break a normal MyDOS 4.50 disk. If one of you programmer types gets excited, maybe you could fix this without utilizing 65816 op codes? Bob Quote Link to comment Share on other sites More sharing options...
+Larry Posted March 1, 2012 Share Posted March 1, 2012 Are you suggesting that patching TBXL likely can't fix this problem? But you've got a good point. Lots of other things load and run just fine, but the body of experience with the 65816 is limited. There certainly may be more. But TBXL is a "hot-button" issue to me. Not being able to run one of the very best applications on a 65816 is a bummer. But then again, I suspect that Charles Marslett never dreamed of someone using his Dos on a 65816. -Larry > I fail to see how patching TBXL will fix this. It's using the same INIT mechanism that any other executable uses. Better to patch DOS than dozens of executables which might exhibit the same problem, surely? < Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 1, 2012 Share Posted March 1, 2012 (edited) Would a swap routine not work in this context? 1282 jsr swapiocb pla tax pha jsr doinit pla tax pha jsr swapiocb ... swapiocb ldy #0 cpsicb lda ichid,x pha lda ichidz,y sta ichid,x pla sta ichidz,y inx iny cpy #16 bne cpsicb rts Pad that up with NOPs until it occupies the same amount of space. Unless I've missed something important... Heh... like the fact this code's still too long. How about saving X inside the subroutine: 1280 jsr swapiocb jsr doinit jsr swapiocb jmp ccfile ... swapiocb txa pha ldy #0 cpsicb lda ichid,x pha lda ichidz,y sta ichid,x pla sta ichidz,y inx iny cpy #16 bne cpsicb pla tax rts ... ccfile (12A5) I make that the requisite 37 bytes long. ...blast - Y indexed ZP references are 3 bytes long, not 2... oh well. Edited March 1, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 1, 2012 Share Posted March 1, 2012 (edited) Wow... this is as addictive as the original bug hunt. I swapped X and Y to utilize ZP,X addressing and now fall into the swap routine second time around: 1 = 0020 ichidz equ $20 2 = 0340 ichid equ $340 3 = 1300 doinit equ $1300 4 = 12A5 ccfile equ $12A5 5 6 org $1280 7 8 1280 8A txa 9 1281 90 06 bcc swapiocb 10 1283 init2 11 1283 48 pha 12 1284 20 00 13 jsr doinit 13 1287 68 pla 14 1288 38 sec 15 16 1289 swapiocb 17 1289 08 php 18 128A 48 pha 19 128B A8 tay 20 128C A2 00 ldx #0 21 128E cpsicb 22 128E B9 40 03 lda ichid,y 23 1291 48 pha 24 1292 B5 20 lda ichidz,x 25 1294 99 40 03 sta ichid,y 26 1297 68 pla 27 1298 95 20 sta ichidz,x 28 129A C8 iny 29 129B C8 inx 30 129C E0 10 cpx #16 31 129E 90 EE bcc cpsicb 32 12A0 68 pla 33 12A1 AA tax 34 12A2 28 plp 35 12A3 return 36 12A3 90 DE bcc init2 It's the right size, but I haven't tested it. X should be restored for the INIT routine and when CCFILE is reached. Edited March 1, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 1, 2012 Share Posted March 1, 2012 (edited) Above patch tested with MyDOS 4.50 and TBXL - works on standard 6502 setup. Here's a patched ATR: ...EDIT - messed up there. Forgot MyDOS won't execute XEXs from the H: drive, so the patch hadn't taken. I'll have to look at it tomorrow. Edited March 1, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+JAC! Posted March 1, 2012 Share Posted March 1, 2012 Well, sure it works - this file is not patched :-) Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 1, 2012 Share Posted March 1, 2012 See above. Goodnight... Quote Link to comment Share on other sites More sharing options...
+JAC! Posted March 1, 2012 Share Posted March 1, 2012 Nice "JSR" using CLC/SEC, BTW. Good night :-) Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 2, 2012 Share Posted March 2, 2012 (edited) Thanks. What a difference a day makes. A bug I'd corrected in the listing above hadn't been fixed in my assembly source. Here's the modified DOS: MYDOS450_Wide_Patch.atr I patched it, wrote DOS to disk, rebooted, checked the new code's there, and ran TB. Seems to work. Here's a patcher to use with MyDOS 4.50: md45wide.xex We need to ensure that the swapping rather than duplicating of the IOCB doesn't break anything. Source for the patcher: ICCOM equ $342 ICSTA equ $343 ICBADR equ $344 ICBLEN equ $348 ICAUX1 equ $34A ICAUX2 equ $34B ICAUX3 equ $34C ICAUX4 equ $34D ICAUX5 equ $34E CIOV equ $E456 ichidz equ $20 ichid equ $340 doinit equ $1300 ccfile equ $12A5 target equ $1280 newcode equ $4000 ptr1 equ $80 ptr2 equ $82 ptr3 equ $84 org $2000 .proc start jsr print .byte 125,'MyDOS 4.50 WIDE Patcher',155 .byte '(c) 2012 FJC',155 .byte 155,0 jsr detect_target bne wrong_version jsr print .byte 'Patch DOS [Y/N]?',0 jsr getkey pha jsr print .byte 155,0 pla cmp #'Y' beq do_patch cmp #'y' bne no_patch do_patch jsr patch jsr print .byte 155,'Complete. Please write DOS to disk.',155,0 no_patch jsr presskey jmp ($0a) wrong_version jsr print .byte 'Error: Incorrect MyDOS Version!',155,0 jsr presskey jmp ($0a) .endp .proc patch ldy #[patch_end-patch_start] patch1 lda newcode-1,y sta target-1,y dey bne patch1 rts .endp .proc detect_target ldy #[patch_end-patch_start] detect1 lda target-1,y cmp target_code-1,y bne wrong_byte dey bne detect1 wrong_byte rts .endp .proc print ; inline print pla clc adc #1 sta ptr1 pla adc #0 sta ptr1+1 jsr printstring inc ptr1 bne *+4 inc ptr1+1 jmp (ptr1) .endp ; ; .proc printax ; sta ptr1 ; stx ptr1+1 ; fall into printstring ; .endp .proc printstring printloop ldy #0 lda (ptr1),y beq printdone jsr putchar inc ptr1 bne printloop inc ptr1+1 bne printloop printdone rts .endp ; .proc putchar pha ldx #0 lda #11 sta iccom,x lda #0 sta icbadr,x sta icbadr+1,x sta icblen,x sta icblen+1,x pla jmp ciov .endp .proc presskey jsr print .byte 'Press a key...',0 jsr getkey rts .endp .proc getkey ldx #32 lda #12 sta iccom,x jsr ciov ldx #32 lda #3 sta iccom,x lda #< kname sta icbadr,x lda #> kname sta icbadr+1,x lda #3 sta icblen,x lda #0 sta icblen+1,x lda #4 sta icaux1,x lda #0 sta icaux2,x jsr ciov lda #7 sta iccom,x lda #0 sta icblen,x sta icblen+1,x jsr ciov pha ldx #32 lda #12 sta iccom,x jsr ciov pla rts .endp target_code .byte $8a,$48,$a0,$f4,$b9,$2c,$ff,$9d .byte $40,$03,$e8,$c8,$d0,$f6,$68,$aa .byte $48,$20,$00,$13,$68,$aa,$48,$a0 .byte $f4,$bd,$40,$03,$99,$2c,$ff,$e8 .byte $c8,$d0,$f6,$68,$aa kname .byte 'K:',155 ; org $1280,$4000 patch_start txa bcc swapiocb init2 pha jsr doinit pla sec swapiocb php pha tay ldx #0 cpsicb lda ichid,y pha lda ichidz,x sta ichid,y pla sta ichidz,x iny inx cpx #16 bcc cpsicb pla tax plp return bcc init2 patch_end org $2e0 .word start Edited March 2, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+Larry Posted March 2, 2012 Share Posted March 2, 2012 Hi Jon- Thanks kindly for your MyDos efforts! I can only test your patch on the 1200XL side of the 65816 WIDE right now, but it does seem to work fine there. It loads and comes up. I also tested it on a regular 800XL , and it also loads TBXL fine. But I can detect a difference in the load versus regular 4.50 (on the 800XL). At the end of the load on your patched version, MyDos goes back and checks sector 1 of D1:, does a status check, and then reads all the directory sectors of D1:. Doesn't seem to affect anything, just different. Regular 4.50 doesn't do that. Would you expect this? -Larry Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.