Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
New bug found in the ROM
76 views
Skip to first unread message
Andrew Owen
May 20, 2012, 3:15:00 PM5/20/12
to
Battle Bunny reported this one:
PRINT PAPER 5;1;STR$ 234
STR$ doesn't preserve the temporary attribute. The inline fix is as follows:
org 0x361f
fp_str_str:
ld a, (attrt) ; fix
ex af, af' ;
ld bc, 0x0001
rst bc_spaces
ld (k_cur), hl
push hl
ld hl, (curchl)
push hl
ld a, 0xff
call chan_open
call print_fp
pop hl
call chan_flag
ex af, af' ; fix
ld (attrt), a ;
pop de
ld hl, (k_cur)
and a
sbc hl, de
ld b, h
ld c, l
call stk_sto_str
ex de, hl
ret
PRINT PAPER 5;1;STR$ 234
STR$ doesn't preserve the temporary attribute. The inline fix is as follows:
org 0x361f
fp_str_str:
ld a, (attrt) ; fix
ex af, af' ;
ld bc, 0x0001
rst bc_spaces
ld (k_cur), hl
push hl
ld hl, (curchl)
push hl
ld a, 0xff
call chan_open
call print_fp
pop hl
call chan_flag
ex af, af' ; fix
ld (attrt), a ;
pop de
ld hl, (k_cur)
and a
sbc hl, de
ld b, h
ld c, l
call stk_sto_str
ex de, hl
ret
jgharston
May 20, 2012, 10:14:27 PM5/20/12
to
Andrew Owen wrote:
> STR$ doesn't preserve the temporary attribute.
Oooo. You live and learn.
> STR$ doesn't preserve the temporary attribute.
As it's CHAN_FLAG that changes ATTR_T, a fix can be done at the
CALL CHAN_FLAG point:
POP HL
CALL str_fix ; was CALL CHAN_FLAG
POP DE
elsewhere:
str_fix:
LD A,(ATTR_T)
EX AF,AF'
CALL CHAN_FLAG
EX AF,AF'
LD (ATTR_T),A
RET
Noted for my next update of JGH-ROM ;)
JGH
Geoff Wearmouth
May 21, 2012, 4:53:35 AM5/21/12
to
On May 21, 3:14 am, jgharston <j...@arcade.demon.co.uk> wrote:
> Andrew Owen wrote:
> > STR$ doesn't preserve the temporary attribute.
>
> Oooo. You live and learn.
>
> As it's CHAN_FLAG that changes ATTR_T, a fix can be done at the
> CALL CHAN_FLAG point:
> Andrew Owen wrote:
> > STR$ doesn't preserve the temporary attribute.
>
> Oooo. You live and learn.
>
> As it's CHAN_FLAG that changes ATTR_T, a fix can be done at the
> CALL CHAN_FLAG point:
> Noted for my next update of JGH-ROM ;)
Those are neat solutions to the problem.
It also cures the example that John Elliott once had in his sig.
10 BORDER 3 : PLOT VAL STR$ 128, VAL STR$ 100
My own solution to these problems was to open stream $FE
at the start of the CLASS_09 routine and while it cured John's bug
it does not cure the example provided by Battle Bunny.
A nice fix with its origins in the SAM Coupe.
I have noted it for the next update of GW03.ROM :-)
My solution, which is also used in Open-SE BASIC would appear to be
redundant.
--
G.
dott.Piergiorgio
May 21, 2012, 5:15:30 AM5/21/12
to
quirks and tricks of sinclair basic, the next step should be a
not-so-compatible improved basic ? and replacing the byte-consuming
storage of variable with a more efficient one, can give or take bytes in
the 4/8/16K bytes of ROM space ?
Best regards from Italy,
dott. Piergiorgio.
roger...@gmail.com
May 21, 2012, 12:02:03 PM5/21/12
to
anyo
ne1 understand why using push to print a page of text is not an option - other than that isnt how the rom does it?
Andrew Owen
May 21, 2012, 5:33:32 PM5/21/12
to
On 21/05/2012 09:53, Geoff Wearmouth wrote:
> I have noted it for the next update of GW03.ROM :-)
If you're revisiting GW03 you might want to fix the PAUSE bug,
> I have noted it for the next update of GW03.ROM :-)
summarized thus by Woody:
"Think it was the LastK flag (bit 5 of [23611]) being set prior to the
pause prematurely ending the pause immediately... Quick example.. FOR N
= 1 TO 100 : NEXT N : PAUSE 0 (Run, press a key. No pause!)... As in the
ROM doesn't clear bit 5, [23611] before the first test after the halt op."
> My solution, which is also used in Open-SE BASIC would appear to be
> redundant.
Andrew Owen
May 21, 2012, 5:41:42 PM5/21/12
to
On 21/05/2012 10:15, dott.Piergiorgio wrote:
> mhm.... now that we have a basic more or less fully compatible with the
> quirks and tricks of sinclair basic, the next step should be a
> not-so-compatible improved basic ? and replacing the byte-consuming
> storage of variable with a more efficient one, can give or take bytes in
> the 4/8/16K bytes of ROM space ?
You've got three main choices:
> mhm.... now that we have a basic more or less fully compatible with the
> quirks and tricks of sinclair basic, the next step should be a
> not-so-compatible improved basic ? and replacing the byte-consuming
> storage of variable with a more efficient one, can give or take bytes in
> the 4/8/16K bytes of ROM space ?
Geoff's GW03.ROM fixes almost all the bugs, adds some useful features
like block delete, renumber, a streams lister, and a tokenizer, but is
still probably around 99% compatible with the original.
Geoff's SC01.ROM is barely compatible with anything but presents the
Spectrum ROM as originally intended, including all the IF1 functionality.
I believe OpenSE BASIC is as, let's say developed rather than improved
as some people might not consider the changes an improvement, as it is
possible to make Sinclair BASIC without becoming completely
incompatible. It has a vast amount of stuff packed in it (see the recent
SE BASIC thread), for example I'm not aware of any other 16K ROMs with a
detokenizer. It's also the only replacement ROM that is free open source
software, being licensed under the GPLv2 thanks to the generosity of
John Grant and Andrew Wright.
Andrew Owen
May 21, 2012, 5:55:26 PM5/21/12
to
On 21/05/2012 22:33, Andrew Owen wrote:
> Can I assume this applies to class-07 as well as class-09?
Actually, after testing, OpenSE BASIC still needs the call to streamfe,
> Can I assume this applies to class-07 as well as class-09?
for both classes.
Chris Young
May 22, 2012, 1:12:06 PM5/22/12
to
On Mon, 21 May 2012 22:41:42 +0100 da kidz on comp.sys.sinclair were rappin'
to MC Andrew Owen:
> It's also the only replacement ROM that is free open source
> software, being licensed under the GPLv2 thanks to the generosity of
> John Grant and Andrew Wright.
Isn't there another one created from the ground up to be compatible
with the original ROM but using none of the original code? Or did I
imagine it? Think it was intended so Fuse could include it without
repurcussions (as the original ROM, although freely distributable with
emulators, is not free OSS).
Usual disclaimer applies!
Chris
--
+-------------------------------------------+
| Unsatisfactory Software - "because it is" |
| http://www.unsatisfactorysoftware.co.uk |
| Your Sinclair: A Celebration |
+- http://www.yoursinclair.co.uk -----------+
DISCLAIMER: I may be making all this stuff up again.
to MC Andrew Owen:
> It's also the only replacement ROM that is free open source
> software, being licensed under the GPLv2 thanks to the generosity of
> John Grant and Andrew Wright.
with the original ROM but using none of the original code? Or did I
imagine it? Think it was intended so Fuse could include it without
repurcussions (as the original ROM, although freely distributable with
emulators, is not free OSS).
Usual disclaimer applies!
Chris
--
+-------------------------------------------+
| Unsatisfactory Software - "because it is" |
| http://www.unsatisfactorysoftware.co.uk |
| Your Sinclair: A Celebration |
+- http://www.yoursinclair.co.uk -----------+
DISCLAIMER: I may be making all this stuff up again.
Duncan Snowden
May 22, 2012, 2:32:05 PM5/22/12
to
On 22 May 2012 18:12:06 +0100
Guidelines when he was trying to get it in there, but as far as I
remember they reluctantly accepted Amstrad's okay-for-emulation
"licence" as being acceptable (although I think it's in their "non-free"
repo).
Having said that, I think you're right in saying there is another
"clean" ROM out there, but I'll hitch a ride on your disclaimer.
--
Duncan Snowden.
"Chris Young" <chris....@mail-filter.com> wrote:
> Isn't there another one created from the ground up to be compatible
> with the original ROM but using none of the original code? Or did I
> imagine it? Think it was intended so Fuse could include it without
> repurcussions (as the original ROM, although freely distributable with
> emulators, is not free OSS).
I recall Phil having a bit of trouble with the Debian Free Software
> Isn't there another one created from the ground up to be compatible
> with the original ROM but using none of the original code? Or did I
> imagine it? Think it was intended so Fuse could include it without
> repurcussions (as the original ROM, although freely distributable with
> emulators, is not free OSS).
Guidelines when he was trying to get it in there, but as far as I
remember they reluctantly accepted Amstrad's okay-for-emulation
"licence" as being acceptable (although I think it's in their "non-free"
repo).
Having said that, I think you're right in saying there is another
"clean" ROM out there, but I'll hitch a ride on your disclaimer.
--
Duncan Snowden.
Guesser
May 22, 2012, 2:39:10 PM5/22/12
to
On 22/05/2012 18:12, Chris Young wrote:
> Isn't there another one created from the ground up to be compatible
> with the original ROM but using none of the original code?
Do you mean Open82? http://open82.sourceforge.net/ or the earlier
> Isn't there another one created from the ground up to be compatible
> with the original ROM but using none of the original code?
OpenZXRom http://matt.west.co.tt/category/spectrum/openzxrom/ (which I
believe morphed into the other at some point)
Both sort of work for loading some machine code programs but neither are
really usable for anything else
Chris Young
May 22, 2012, 3:04:00 PM5/22/12
to
On Tue, 22 May 2012 19:39:10 +0100 da kidz on comp.sys.sinclair were rappin'
to MC Guesser:
> On 22/05/2012 18:12, Chris Young wrote:
> > Isn't there another one created from the ground up to be compatible
> > with the original ROM but using none of the original code?
>
> Do you mean Open82?
Ah, yes, that's the one.
to MC Guesser:
> On 22/05/2012 18:12, Chris Young wrote:
> > Isn't there another one created from the ground up to be compatible
> > with the original ROM but using none of the original code?
>
> Do you mean Open82?
Andrew Owen
May 22, 2012, 7:27:54 PM5/22/12
to
OpenZX was renamed Open82, as BSkyB still own the rights to the ZX name.
However, as Guesser says it was very incomplete. I think the project is
now dead as OpenSE BASIC does the job OpenZX was intended to do; namely,
enable FUSE to be in Debain main, which it will be in Debian 7 apparently.
However, as Guesser says it was very incomplete. I think the project is
now dead as OpenSE BASIC does the job OpenZX was intended to do; namely,
enable FUSE to be in Debain main, which it will be in Debian 7 apparently.
BloodBaz
May 25, 2012, 8:22:17 PM5/25/12
to
On Monday, May 21, 2012 9:53:35 AM UTC+1, Geoff Wearmouth wrote:
> It also cures the example that John Elliott once had in his sig.
>
> 10 BORDER 3 : PLOT VAL STR$ 128, VAL STR$ 100
>
Wow. I can understand ATTR_T getting accidently reset but a BORDER change affecting PAPER, well that is pretty cool!
> It also cures the example that John Elliott once had in his sig.
>
> 10 BORDER 3 : PLOT VAL STR$ 128, VAL STR$ 100
>
jgharston
Jun 11, 2012, 7:19:15 AM6/11/12
to
jgharston wrote:
> Andrew Owen wrote:
> > STR$ doesn't preserve the temporary attribute.
>
> Andrew Owen wrote:
> > STR$ doesn't preserve the temporary attribute.
>
> As it's CHAN_FLAG that changes ATTR_T, a fix can be done at the
> CALL CHAN_FLAG point:
Doing some checks before updating my JGH-ROM; it's not just
> CALL CHAN_FLAG point:
ATTR_T that's changed, all three print state variables are
changed, ATTR_T, MASK_T and PFLAG:
0D4D TEMPS XOR A
LD HL,(ATTR_P) ; Get ATTR_P and MASK_P
...
0D5B TEMPS1 LD (ATTR_T),HL ; Set ATTR_T and MASK_T
LD HL,PFLAG
; Copy PFLAG_P to PFLAG_T
changing the colour 8/9 and inverse/over states as well
as the colour 0-7 states.
So, str_fix needs to be:
str_fix:
LD HL,(ATTR_T)
PUSH HL
LD A,(PFLAG)
PUSH AF
CALL CHAN_FLAG
POP AF
LD (PFLAG),A
POP HL
LD (ATTR_T),HL
RET
similar to the code at 0C93-0C9A and 0CCA-0CD1. I wonder if
I can somehow combine both bits of code.
JGH
Andrew Owen
Jun 11, 2012, 1:15:12 PM6/11/12
to
On 11/06/2012 12:19, jgharston wrote:
> Doing some checks before updating my JGH-ROM; it's not just
> ATTR_T that's changed, all three print state variables are
> changed, ATTR_T, MASK_T and PFLAG:
>
> 0D4D TEMPS XOR A
> LD HL,(ATTR_P) ; Get ATTR_P and MASK_P
> ...
> 0D5B TEMPS1 LD (ATTR_T),HL ; Set ATTR_T and MASK_T
> LD HL,PFLAG
> ; Copy PFLAG_P to PFLAG_T
>
> changing the colour 8/9 and inverse/over states as well
> as the colour 0-7 states.
I would have thought INK/PAPER 8/9 was less likely to occur as an inline
> Doing some checks before updating my JGH-ROM; it's not just
> ATTR_T that's changed, all three print state variables are
> changed, ATTR_T, MASK_T and PFLAG:
>
> 0D4D TEMPS XOR A
> LD HL,(ATTR_P) ; Get ATTR_P and MASK_P
> ...
> 0D5B TEMPS1 LD (ATTR_T),HL ; Set ATTR_T and MASK_T
> LD HL,PFLAG
> ; Copy PFLAG_P to PFLAG_T
>
> changing the colour 8/9 and inverse/over states as well
> as the colour 0-7 states.
instruction, but you're right that all bases should be covered.
> So, str_fix needs to be:
> str_fix:
> LD HL,(ATTR_T)
> PUSH HL
> LD A,(PFLAG)
> PUSH AF
> CALL CHAN_FLAG
> POP AF
> LD (PFLAG),A
> POP HL
> LD (ATTR_T),HL
> RET
>
> similar to the code at 0C93-0C9A and 0CCA-0CD1. I wonder if
> I can somehow combine both bits of code.
be to tell the monitor that the lower border is in use, which would
leave the PFLAG alone.
jgharston
Jun 11, 2012, 2:06:56 PM6/11/12
to
Andrew Owen wrote:
> jgharston wrote:
> > Doing some checks before updating my JGH-ROM; it's not just
> > ATTR_T that's changed, all three print state variables are
> > changed, ATTR_T, MASK_T and PFLAG:
>
> jgharston wrote:
> > Doing some checks before updating my JGH-ROM; it's not just
> > ATTR_T that's changed, all three print state variables are
> > changed, ATTR_T, MASK_T and PFLAG:
>
> Well you could make the common code a subroutine. Another option would
> be to tell the monitor that the lower border is in use, which would
> leave the PFLAG alone.
I've sketched up the following code:
> be to tell the monitor that the lower border is in use, which would
> leave the PFLAG alone.
PO_STATE_SV LD HL,(ATTR_T) ; Save state
EX (SP),HL
LD A,(PFLAG)
PUSH AF
RET
PO_STATE_RS POP HL ; Restore state
POP AF
LD (PFLAG),A
EX (SP),HL
LD (ATTR_T),HL
RET
Which gives:
STR_FIX CALL PO_STATE_SV
CALL CHAN_FLAGS
CALL PO_STATE_RS ; MUST do as a CALL
RET
and lets me squeeze the code into four places in the ROM
where the state is manually saved and restored, eg:
PO_SCR2 DEC (SCR_CT)
JR NZ,PO_SCR3
LD A,&18
SUB B
LD (SCR_CT),A
CALL PO_STATE_SV
; now have 5 spare bytes here
...
LD A,&FE
CALL CHAN_OPEN
CALL PO_STATE_RS
; now have 5 spare bytes here
and in PO_SCR4, OUT_FLASH, and somewhere else I can't remember ATM,
combined with a shared LD A,&FE:JP CHAN_OPEN stub as well.
I'm in the middle of a big Z80 coding spree having discovered
some old screen driver code wot I rote and tryng to understand
what the uncommented code does so I can comment it ;)
JGH
Andrew Owen
Jun 11, 2012, 5:27:17 PM6/11/12
to
On 11/06/2012 19:06, jgharston wrote:
> I'm in the middle of a big Z80 coding spree having discovered
> some old screen driver code wot I rote and tryng to understand
> what the uncommented code does so I can comment it ;)
Before you start, there's a lot to be said for getting rid of magic numbers.
> I'm in the middle of a big Z80 coding spree having discovered
> some old screen driver code wot I rote and tryng to understand
> what the uncommented code does so I can comment it ;)
Chris Young
Jun 11, 2012, 6:00:53 PM6/11/12
to
On Mon, 11 Jun 2012 22:27:17 +0100 da kidz on comp.sys.sinclair were rappin'
to MC Andrew Owen:
There's also a lot to be said for commenting code when it is written.
I still don't bother though.
to MC Andrew Owen:
I still don't bother though.
jgharston
Jun 12, 2012, 1:10:49 AM6/12/12
to
> > jgharston wrote:
> > > I'm in the middle of a big Z80 coding spree having discovered
> > > some old screen driver code wot I rote and tryng to understand
> > > what the uncommented code does so I can comment it ;)
>
> > Before you start, there's a lot to be said for getting rid of magic numbers.
>
> There's also a lot to be said for commenting code when it is written.
I remember writing this code on paper while sat in the garden.
> > > I'm in the middle of a big Z80 coding spree having discovered
> > > some old screen driver code wot I rote and tryng to understand
> > > what the uncommented code does so I can comment it ;)
>
> > Before you start, there's a lot to be said for getting rid of magic numbers.
>
> There's also a lot to be said for commenting code when it is written.
The comments and structural notes were all on the paper coding.
I obviously just typed in the code and didn't bother with the
comments - after all, I had the comments on paper!
Nowadays, comments flow unprompted from my fingers as I type the
code.
JGH
jgharston
Jun 12, 2012, 1:33:16 AM6/12/12
to
jgharston wrote:
> > > Doing some checks before updating my JGH-ROM; it's not just
> > > ATTR_T that's changed, all three print state variables are
> > > changed, ATTR_T, MASK_T and PFLAG:
>
> > > Doing some checks before updating my JGH-ROM; it's not just
> > > ATTR_T that's changed, all three print state variables are
> > > changed, ATTR_T, MASK_T and PFLAG:
>
> I've sketched up the following code:
At http://mdfs.net/Software/Spectrum/Harston is the JGHROM v0.76
incorporating colour preservation in STR$ and INKEY$#n as
documented by Battle Bunny, plus a couple of other little
tweeks I've been thinking about. I surprised myself when I
realised it's eight years since I last worked on the code,
which was essentially just finishing off a few leftovers
from about 1986. I'll have to get the EPROM programmer out
and re-program the EPROM in the Spectrum.
PRINT PAPER 5;1;STR$234 and
PAUSE 0:PRINT PAPER 5;"x";INKEY$#0;"y"
both preserve the colour settings as expected. I though I'd
fixed the INKEY$#0 bug (where nothing is almost always read
from stream 0 when attached to the keyboard due to the
pending key flag being clear). However, the above test
showed it's back to not working again. I think I must have
fixed the fix back out of existance without noticing.
Can anybody remind me of the recommended and/or canonical
fix for INKEY#n when n is attached to "K". Thanks.
JGH
jgharston
Jun 13, 2012, 5:24:10 AM6/13/12
to
jgharston wrote:
> I though I'd fixed the INKEY$#0 bug (where nothing is
> almost always read from stream 0 when attached to the
> keyboard due to the pending key flag being clear).
I was obviously too tired to think properly yesterday, I've
> I though I'd fixed the INKEY$#0 bug (where nothing is
> almost always read from stream 0 when attached to the
> keyboard due to the pending key flag being clear).
redone the tests and it works.
5 REM This works with the JGHROM
10 PRINT INKEY$#0;:GOTO 10
The JGH ROM removes the RES 5,(FLAGS) when opening channel
"K" at &1638 to remove the cancelling of a pending key:
1638 OPT FNorg(&1638) ; Open channel 'K'
1638 FD CB 01 DE SET 3,(IY+1) ; Set 'L' mode, also fixes
INKEY#0 bug
163C ;
The JGHROM sets 'L' input mode as it uses character entry
instead of keyword entry. Otherwise, NOP:NOP:NOP:NOP works.
Now, I just want to get INPUT working from channel "S" :)
JGH
sam coupe
Jun 13, 2012, 9:21:03 AM6/13/12
to
you cant use the snapper disc from velesoft to run 48K snapshots in sim coupe at 6mhz using external ram for code above 32,768 please?
sam coupe
Jun 13, 2012, 9:19:42 AM6/13/12
to
0 new messages