Posted By
gmontag451
on 2022-08-26
05:09:17
|  Plus/4 $FF28 Bug (TEDMON Bug?)
I just discovered the $FF28 bug the hard way! Two days of sifting through my program looking for mistakes...
|
|
Posted By
gmontag451
on 2022-08-26
05:10:46
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Sorry, emojis apparently truncate your post. Here's the rest:
I just discovered the $FF28 bug the hard way! Two days of sifting through my program looking for mistakes...
This site's Plus/4 Encyclopedia says "The cause needs to be better documented" so I can offer at least my reproducible situation: I load a BASIC program which also has a ML program attached to it. I enter the monitor and assemble a single opcode to the program and exit. When I SAVE or print, locations $3058 and $3059 change to $28 and $FF ($FF28 in LO/HI format, which appear as a left parenthesis and pi in the program listing.)
If I assemble code outside of the protected area following the BASIC program the error does not occur. Additionally making changes to the protected area using the monitor's FILL or > commands, or by a BASIC POKE don't trigger the bug. So it seems that the issue has something to do with using the Assembler on code which resides within the area claimed by the program listing.
The Encyclopedia says that the bug occurs when saving files, but I can confirm it also happens when printing. Possibly any serial access will trigger it, although there may be other triggers as well.
As explained in the encyclopedia, typing > 79 00 before exiting the monitor will prevent the issue. The BASIC equivalent of POKE 121,0 also works.
Does a similar issue exist with the C16 or C128 since they both also use TEDMON? I wonder if there are any replacement ROMS such as JiffyDOS which correct this bug?
The Encyclopedia entry
|
|
Posted By
seff
on 2022-08-26
06:36:19
 | Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Indeed, it's fully reproducible:
fire up YAPE:
1. monitor
2. > 3058 11 22
3. a 3000 lda #$00
sta $5000
x
4. dsave "program.prg"
5. monitor
6. m 3050 and voilà
and I have drive 8 in 1551 cpu emulation mode btw
|
|
Posted By
gmontag451
on 2022-08-26
09:26:23
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Thanks seff for a much cleaner example. This also proves my theory wrong about the protected area. In fact this example only triggers the bug when the sta $5000 is assembled, so I'm also wrong about any single change setting it off. This bug seems finicky!
|
|
Posted By
seff
on 2022-08-29
01:54:56
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
We can consult Fred Bowen and Terry Ryan about it  .
And sta $5000 may add more chars to the buffer - my theory.
EDIT:
I tested two scenarios:
1)
ldx #$00 alone will not trigger the defect (2 bytes)
sta $5000 alone will trigger the defect (3 bytes)
2)
saving a memory range using TEDMON will not trigger the defect
saving a Basic program using DSAVE will trigger the defect
And the source code in question is here (ted_basic CR6502/11 version 20.51.10 14-Feb-85 13:5:31):
14577 ; oldclr subroutine
14578 ; clears disk status
14579
CD57 14580 oldclr
CD57 98 14581 tya ;save y
CD58 48 14582 pha
CD59 A5 79 14583 lda dsdesc ;chk for allocation
CD5B F0 0A 14584 beq oldcl1 ;bra if not
CD5D A0 28 14585 ldy #40
CD5F 98 14586 tya
CD60 91 7A 14587 sta (dsdesc+1),y ;length of garbage
CD62 C8 14588 iny
CD63 A9 FF 14589 lda #$ff
CD65 91 7A 14590 sta (dsdesc+1),y ;garbage flaged
14591
CD67 14592 oldcl1
CD67 A9 00 14593 lda #0
CD69 85 79 14594 sta dsdesc ;kill ds$
CD6B 68 14595 pla ;restore y
CD6C A8 14596 tay
CD6D 60 14597 rts
14598
14599 ;.end
14600 ;(05jul84) fab & tvr: garbage collect following ?ds$ crashed due to messy
14601 ; condition of ds$ backpointer. corrected backpointer.
|
|
Posted By
Litwr
on 2022-08-27
07:47:06
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
What a nightmare! Every disk save can corrupt my program. I have tested SAVE"PRG",8 - it corrupts too. I did some debugging - something is wrong about a routine at $CD5D which uses an incorrect value at $7A.
EDIT. LDX#$00 causes the error too but at $304c. The build-in assembler uses area starting at $79 as a buffer for an instruction parameter, this corrupts the work with DS$. So don't use Basic and the built-in assembler together.
|
|
Posted By
TLC
on 2022-08-27
04:44:14
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
This topic popped up on the cbm-hackers mailing list once some time ago. See: http://www.softwolves.com/arkiv/cbm-hackers/15/15561.html
TL;DR: the bug is caused by both TEDMON and Basic disk I/O routines using the same zero page locations. TEDMON uses $77 and a couple of bytes on as a temporary buffer. Basic's clear DS$ routine at $CD57 (which is called by most Basic disk I/O commands) uses $79, $7A and $7B as DS, and the pointer to the last error message i.e. DS$ if my memory serves me well*. Unless DS i.e. $79 is 0 (which it almost certainly is not after having executed some A commands in monitor), the routine will go on writing $28 and $FF to ($7A),Y, which at this time points to somewhere usually $3058. (Other scenarios i.e. other target and content are AFAIR possible.)
For the bug to trigger, it should be enough to assemble something in monitor (e.g. using the A command), then X from monitor, and request a directory (or execute some other Basic disk command).
To completely avoid the bug (even despite sharing memory addresses between Tedmon and Basic), zeroing $79 prior to exiting from monitor should have sufficed.
*Thinking it over, I'm indeed not sure about the "($7A) should point to the DS$ string" part anymore, will need to double check.
|
|
Posted By
Ulysses777
on 2022-08-27
08:28:36
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
When entering an assembly line in TEDMON, the 5th and 6th characters of the instruction (not including spaces) get passed to the BASIC DS$ pointer at $7A-$7B, with any hexadecimal values changed to zeroes. For example, either LDA $00 or STA $AB will put the ASCII value for the zero character ($30) in locations $7A-7B, and adding the Y value of $28, gives you $3058.
So entering an accumulator/implied instruction will have no effect, but for other instructions, if the last instruction entered was a zeropage, absolute or relative instruction, then the corruption will occur at $3058. If it was an immediate or indirect instruction (which enters the dollar character $24 as the 5th char), then the corruption will occur at $304C. And if the last line was invalid, then anything goes 
|
|
Posted By
MMS
on 2022-08-28
06:48:23
 | Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Actually I think you have a lot of free memory in plus/4. Keeping it so close to the main code causes the problem, but you do not want a huge save that's why you put it closer.
In C64 codes that's why they prefer inserting the machine code via poke commands above the BASIC area.
I think there is an other possible solution. Some time ago with the help of gerliczer and George we created a basic loader routine use the kernal code. With that one you can load a file to any place in the memory without changing any of the mentioned memory addresses or even restarting your BASIC code.
After you loaded it you can start with SYS. We used it to load gfx to an unused high address then to copy segments of it to the gfx screen.
but it could be anything, music, fontset or a separate code stored on the floppy disc.
The loader routine is somewhere in the programming section here on Plus4world, from phone it is not that easy to find.
Here it is, can be easily modified, just the load address and the filename need to be changed.
|
|
Posted By
SVS
on 2022-08-28
07:18:48
 | Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Levente said, in the time, that if $79 was not $00, the routine $CD57 does execute:
LDA #$28
STA ($7A),Y (Y=$28)
LDA #$FF
INY
STA ($7A),Y (Y=$29)
Then it is clear that the value staying on $7A,$7B is $3030 (in fact $3030+$28=$3058 that is the address where the bug appears. This confirms what Ulysses says.
|
|
Posted By
seff
on 2022-08-29
01:43:53
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
So to hypothetically patch TEDMON, one would have to find 7 empty bytes in the KERNAL (any recommendation?):
EDIT:
replace the 'x' vector with a new vector (pointer to vector - 1 actually):
>F580 lo_new_vector_minus_1
>F581 hi_new_vector_minus_1
new_vector:
LDA #$00
STA $79
JMP $8003
and I tested the proof of concept with ROM In RAM
|
|
Posted By
Csabo
on 2022-08-28
13:16:47
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Above $FCD1 there's some free space.
|
|
Posted By
Litwr
on 2022-08-28
14:48:15
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
@Csabo IMHO it is better to use an area on ZP, this makes the changes minimal. I can suggest the FAC area at $69.
|
|
Posted By
Csabo
on 2022-08-28
14:52:25
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
But seff specifically said he wanted to patch TEDMON (the KERNAL file that the emulators load).
|
|
|
|
Posted By
Csabo
on 2022-08-30
14:14:55
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Looks good seff, absolutely minimal changes. Hopefully someone will find it useful
|
|
Posted By
Litwr
on 2022-08-30
17:26:08
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
IMHO it would be good to have a special page dedicated to KERNAL patches on this site. One day this may help to build a perfect KERNAL. I remember another patch that allows us to use 19,200 bauds on RS-232C. Maybe there are other patches somewhere...
BTW Atari enthusiasts rewrote their ROM and get Basic 110-130% faster with 100% compatibility with the old ROM!
|
|
Posted By
MMS
on 2022-08-31
16:12:05
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Litwr, great idea, but we need eg. corrected GSHAPE function, not a 100% compatible one
|
|
Posted By
siz
on 2022-09-01
17:21:57
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
@MMS: it depends on your intended use of the ROM. I remember some software (Domino comes to my mind) which used direct ROM calls instead of KERNAL vectors (in this case some tape specific interrupt routines) which were incompatible with JiffyDOS. This has been fixed in Domino Deluxe but there are some other programs in the library for sure.
So yeah, You can write your own ROMs but in the end You need to be able to switch either the ROM to the original or to a different computer for compatiblity reasons.
Of course if the intended use is running BASIC programs without any direct ROM calls then it's fine.
|
|
Posted By
Luca
on 2022-09-02
02:11:05
 | Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Very clever thread, lads! And seff: very well done! An R5 FF28 Kernal fixed BIOS set has been added on Othersi.de archive into the traditional folder /Misc/BIOS/.
@SVS, given that the dedicated Encyclopedia page is signed and supported by you, I expect you would update it with all the fresh news gathered in this thread Do it in your – limited, I know – free time, in the name of FIRE! 
|
|
Posted By
seff
on 2022-09-04
08:29:51
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
@Litwr
To patch RS-232C, one has to fix two defects:
1) The instructions at $EAA7 and $EAA9 have to be swapped to allow null characters to be received:
>EAA7
STA $07D5
BEQ $EAC2
2) A PLA instruction needs to be injected before $EB1E to allow XON/XOFF control characters to be transmitted:
>EB1B
JMP $FCD8
>FCD8
STA $07CF
PLA
JMP $EB1E
Edit:
Here is a patched KERNAL file kernal.318004-05-rs232c.bin based on kernal.318004-05.bin, PAL-G version, revision 5.
The new KERNAL fixes RS-232C defects.
I have no way to test RS-232C though. But it was supposedly tested by R. C. Hemes in 1987 (19,200 baud).
References:
https://archive.org/details/YourCommodoreIssue35Aug87/page/n77/mode/2up
forum/16281
forum/24936
forum/36477
forum/43757
forum/43869
Also, there are 8 bytes free at $CEC5.
|
|
Posted By
Litwr
on 2022-09-03
05:32:34
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
@seff
It is one more step to the perfect Kernal. IMHO it would be better to have fixes in patch/diff format. This would allow a man to manipulate patches and this just occupies much less space.
|
|
Posted By
seff
on 2022-09-04
09:03:32
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
@Litwr
Edit:
Agree, we can get patch files in the diff format:
$ bsdiff -OriginalROM PatchedROM > kernal.318004-05-ff28.patch
$ bspatch OriginalROM NewROM kernal.318004-05-ff28.patch
$ diff <(xxd -c 8 -g 1 OriginalROM) <(xxd -c 8 -g 1 PatchedROM)
We need to keep track how these patches overlay, because we only have limited bytes free in the KERNAL (BASIC) ROM.
I thought of relocatable patches, but it may be over-engineered.
Here is a first batch of KERNAL patches. (How and where can I upload them to Plus4World?).
|
|
Posted By
JamesD
on 2022-09-15
14:42:58
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
With these patches work with the NTSC ROM? (I would think so but...)
|
|
|
|
Posted By
SVS
on 2022-09-17
06:47:43
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Does exist a mod ROM with both $FF28 and RS232 patches?
Thank you
|
|
Posted By
seff
on 2022-09-18
07:04:18
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
@SVS
There you go:
$ bspatch kernal.318004-05.bin kernal.318004-05.temp.bin kernal.318004-05-ff28.patch
$ bspatch kernal.318004-05.temp.bin kernal.318004-05.new.bin kernal.318004-05-rs232c.patch
kernal.318004-05.new.bin (PAL-G)
$ bspatch kernal.318005-05.bin kernal.318005-05.temp.bin kernal.318004-05-ff28.patch
$ bspatch kernal.318005-05.temp.bin kernal.318005-05.new.bin kernal.318004-05-rs232c.patch
kernal.318005-05.new.bin (NTSC)
What's next? GSHAPE? I can add more patches, provided that we agree on priorities...
|
|
Posted By
SVS
on 2022-09-18
14:24:55
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Thank you seff.
I can propose as next bug-solving, the garbage screen when exiting from Monitor or when a Basic error appears (while using a new charset on Ram). The solution could be:
LDA $FF12
ORA #%100
STA $FF12
|
|
Posted By
seff
on 2022-09-19
01:31:38
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Exiting from MONITOR can be fixed together with the $FF28 defect (the 'X' vector) easily.
Fixing the BASIC error - I need to locate the routine.
This also means to take a more holistic approach to fixing, i.e. fixing the KERNAL and BASIC ROMs and having governance over it.
Maybe I will create a GitHub repo.
|
|
Posted By
MMS
on 2022-09-21
14:04:58
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
@seff
Thank you.
Sometimes I feel dumb compared to you, guys...
|
|
Posted By
Litwr
on 2022-09-20
01:55:20
| Re: Plus/4 $FF28 Bug (TEDMON Bug?)
Maybe I will create a GitHub repo.
What a good idea! It would be great to create a bug-fixed Kernal generator. We select a bug list (and optionally PAL/NTSC) and get a fixed Kernal.
|
|
