Jump to content
IGNORED

TurboBasicXL problem


bob1200xl

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by JAC!
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by flashjazzcat
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

 

 

post-14708-0-29913300-1330627791_thumb.jpg

Link to comment
Share on other sites

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? <

Link to comment
Share on other sites

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. :D

 

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 by flashjazzcat
Link to comment
Share on other sites

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 by flashjazzcat
Link to comment
Share on other sites

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 by flashjazzcat
Link to comment
Share on other sites

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 by flashjazzcat
Link to comment
Share on other sites

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

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...