Basic Poke statement doing odd things

[Steve Cousins]

Hi everyone

New guy here.

I've been writing assembler and downloading it by embedding the machine code as data in a basic program.

I have successfully managed to download and run programs several kbytes long, but I have a strange problem.

The mystery boils down to odd behaviour (yes, UK spelling) of the Poke statement.

This works fine:

10 POKE &H4000,2

20 PRINT ".";

30 GOTO 10

But this does not:

10 POKE &H4000,1

20 PRINT ".";

30 GOTO 10

In the first case I get lots of dots displayed on the terminal, as expected.

In the second case I have to press a key on the terminal before each dot is displayed.

For some reason the Poke statement does not like the data value 1, but is happy with all other values I've tried.

I've tried different addresses, but all seem to do the same.

I've tried two different terminal programs - same result.

Other tests seem to indicate it is nothing to do with the Print statement. I first noticed to problem when I was reading from data statements and poking the values to memory, without any printed output. Even short programs seemed to just hang and it took me a while to discover that a few key presses 'fixed' it, allowing the machine to be poked into memory and run.

Am I missing something really silly and obvious???

I'm using a new 'RC2014 Pro' kit which I received earlier this week. Everything seems to be working but it is a new build so isn't proven reliable hardware. I don't have any other RC2014 systems, so can't rule out a hardware issue.

My RC2014 is a backplane Pro, 64k RAM, paged ROM, dual clock, dual serial SIO/2, Z80 cpu, digital I/O (with diodes).

I'm running 32k MSBASIC.

I'm hoping someone can tell me I'm an idiot because... <appropriate explanation required>

Thanks for taking the trouble to read about my problem. Any comments appreciated.

Steve

[Jay Cotton]

This is a good one.  (Bad bug)....   

I wonder if you can trick the code with something like....

10 POKE &H4000,2-1

Would that work?  If so I'd be looking at the basic interpreter, else

some kind of data line problem....  

Lets just see.  And as expected I can't reproduce the bug on my other machine.

I'm temped to call it a hardware bug.  I just don't see how (yet).

10 POKE &H4000,1

20 PRINT ".";

30 GOTO 10

Ok

run

.............................................................................................

and so on.

[Steve Cousins]

Thanks Jay

I hadn't thought of trying that. So I did...

10 POKE &H4000,2-1

Same result.

5 d=1

10 POKE &H4000,d

Same result.

Also been testing with address &H9999. Same result.

I've removed the digital I/O module so I have minimal hardware. Same result.

I reduced clock speed to 0.3072Mhz (serial = 4800bps), primarily to help me see what is going on with my very slow scope. Same result.

Scoping the bus all looks reasonable.

I tried reconfigured links and used the 56k basic. Same result.

I did find some other data values caused problems. The data value 129 (also with bit 0 set) caused the program to hang after a while. Could not exit the basic program and had to reset. Yet I've been able to poke several kbytes of code this way only having to press a key when data byte 1 is encountered. So it looks marginal.

I can already feel the pain where I'm going to kick myself...

Steve

[Chris Scullion]

If it helps at all, I ran the above samples in the rc2014 emulator under Linux and the bad behavior is not seen. Also tried it on my RC2014 Mini and the problem is not seen there either.

[Steve Cousins]

Thanks Chris

Yes, it helps to get reports confirming that the code should run. 

Your Mini system is not the same configuration as my RC2014, but the evidence is adding up to it being an odd hardware problem at this end.

I guess I'll figure it out eventually.

Steve

[Ed Brindley]

Hi Steve,

I can confirm that both programs work OK on my RC2014 with 64k RAM, "old school" ACIA serial, RAM, ROM and clock generator boards.

I don't have the pageable ROM or SIO/2 serial board so can't test with those unfortunately.

Cheers,
Ed

[Steve Cousins]

Thanks Ed

Much appreciated. Really looking more and more like an odd hardware fault.

Like the look of your modules by the way. My first computer did not have any sound, so I'm rather attracted to that add-on.

Steve

[Jay Cotton]

A mad idea, pull out the ram chip and make sure all the legs are straight.  I had a problem with a folded leg,

it led to a marry chase.

jc

On Saturday, November 11, 2017 at 3:22:33 PM UTC-8, Steve Cousins wrote:

[Steve Cousins]

Hi Jay

Thanks for the suggestion, but I've already tried that. Had all the chips out. Been over everything with a magnifying glass. If its mechanical I can't see it.

I've also double checked all the links. I've tried moving the boards around on the backplane. Running out of things to try.

I think everything physically looks ok, but until you find the problem you can't really be sure you haven't missed something.

If this turns out to be a silly mistake or misunderstanding on my part I'll have to go to the back classroom for quite a while!!

Unfortunately I don't have many of the necessary components to try substitutions.

The next step may well be to get a few spares. I need some anyway for projects I have planned.

I have a feeling it is something to do with the SIO/2 and interrupts, even though the key presses are still required when not printing the dots. Just a hunch really as no evidence.

With such simple electronics it seems odd that it is proving difficult to trace. I will get to the bottom of this eventually.

Steve

[Ed Brindley]

Thanks Steve.

Good luck debugging the problem!

Ed

[Spencer Owen]

Hi Steve,

Yeah, it looks like you've found a weird bug - but the good news is that it is repeatable :-)  

So, although I run a RC2014 Pro as my daily driver, I only run CP/M on there, and if I want to use BASIC, I run mBASIC, where that bug doesn't happen.  Or, indeed anywhere else in CP/M.  Therefore, I'd be happy to say that it's not hardware related (Sorry, I bet you wish I'd checked before you got your magnifying glass out!).

I tend to agree with your suspicions that it's interrupts and SIO/2 related as it doesn't happen with the 68B50 UART.  The same BASIC code is used for either implementation, however the initialisation code is different between the two.  (However, the same initialisation code is used for the 32k SIO/2 BASIC and the 56k SIO/2 BASIC and they both show the same symptoms).

It might take me a little while to track things down, but hopefully I can come back to you with a fix soon.

Cheers

Spencer

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/099a2aba-fc23-4f63-9bce-ea2c21fe3e6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Cousins]

Well that's an unexpected twist Spencer.

I had reached the point where I was sure it was a fault on my hardware.

Thanks for looking into this. I'll await further news.

Steve

[Steve Cousins]

Update:

This program should give a little light show on the digital I/O module.

10 OUT 0,1

15 GOSUB 100

20 OUT 0,2

25 GOSUB 100

30 OUT 0,4

40 END

100 FOR Z=1 TO 2000

120 NEXT

199 RETURN

What actually happens is the first OUT statement executes ok then hangs until a key is pressed on the terminal. A short delay is seen before the second OUT statement executes. Same happens after the second OUT statement.

If I remove the delays, giving just the listing below, the lights just flicker as expected.

10 OUT 0,1

20 OUT 0,2

30 OUT 0,4

So it appears the waiting for a character to be input from the terminal is caused by the subroutine call or the start of the FOR loop.

Steve

 

[Scott Lawrence]

I remember there was talk about having an informational wiki for the 'RC.  Having a repository of code snippets and demonstrations of using hardware was part of that and this would be perfect content to put in there.  Did that ever happen?

S

Sent from your iPhone.

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/074bcf74-460c-4566-9d36-2ad1004c3df1%40googlegroups.com.

[Mark Ericksen]

I see the same type issue when using the SIO/2 interface and not the 68B50 interface.

10 FOR N=1 to 100

20 PRINT N

30 NEXT N 

After keying this program in, typing RUN, and hitting the ENTER key does nothing until I hit the ENTER key a second time.

[J.B. Langston]

It looks like this isn't specific to the poke statement. I was trying to get the Mandelbrot BASIC demo running on my RC2014 Pro and I found that it pauses before drawing each line until a key is pressed.  

After reading Spencer's comment about using MBASIC, I thought I'd try to get it running there but no luck there either. It doesn't display correctly. I think that MBASIC is counting the number of characters on each line and wrapping at what it thinks is 80 characters. The problem is that it counts the ANSI control sequences as characters in the line even though they don't actually get displayed, so it only displays a few characters on each line before it wraps.  Anybody know a way to fix this?

[Steve Cousins]

Hi JB

Yes, I too found the pauses in ROM BASIC occur in other places than the POKE statement originally reported.

I think MBASIC's WIDTH statement may fix your problem (see below).

Steve

Format: WIDTH tLPRINT] <integer expression> 

Versions: Extended, Disk 

Purpose: To set the printed line width in number of 
characters for the terminal or line printer. 

Remarks: If the LPRINT option is omitted, the line width 
is set at the terminal. If LPRINT is included, 
the line width is set at the line printer, 

< integer expression> must have a value in the 
range 15 to 255. The default width is 72 
characters. 

If <integer expression> is 255, the line width 
is "infinite," that is, BASIC never inserts a 
carriage return. However, the position of the 
cursor or the print head, as given by the POS or 
LPOS function, returns to zero after position 
255. 

[J.B. Langston]

That fixed it. My RC2014 is mandelbrotting away now.  BTW, what reference did you quote that information from?

[Richard Deane]

Which other values have you tried? 3 would set same bit as 1, also try 2,4,8,16 etc for other bits?

You've probably tried this already :)

richard

On Saturday, 11 November 2017 23:22:33 UTC, Steve Cousins wrote:

[Steve Cousins]

Hi JB

I found this with google:

https://archive.org/stream/BASIC-80_MBASIC_Reference_Manual/BASIC-80_MBASIC_Reference_Manual_djvu.txt

I was fairly confident there was a width command, but googled to check and found the above.

Steve

[Steve Cousins]

I thought it was about time this bug got fixed so I've had a little play.

I believe I've solved the problem.

The attached HEX file is for ROM BASIC for use with the SIO module and using 32K RAM for the BASIC program.

Steve

On Saturday, 11 November 2017 23:22:33 UTC, Steve Cousins wrote:

[Tom Szolyga]

HI Steve,

Would you consider uploading the source or providing a link to the source?

Thanks,

Tom

[Steve Cousins]

Hi Tom

I would be happy to but I don't have the source. 

I fixed it with a hex editor.

If anyone knows where the source is I'd be happy to apply the fix and post it here.

Steve

[Ed Brindley]

This is purely a guess based on the hex in the RC2014 repo being called INTSIO.HEX, but I reckon it's probably derived from Scott Baker's SIO implementation...

https://github.com/sbelectronics/rc2014/blob/master/asm/intsio.asm

Cheers,
Ed

[Steve Cousins]

Thanks Ed, that looks close.

[Steve Cousins]

Unless I'm getting all confused over these different files, here's the whole thing explained.

The files attached are:

Grant Searle's original boot monitor.asm

Dr Baker's modified version of Grant's boot monitor.asm 

(actual source code for official ROM - missing)

Spencer is the only one who can provide the actual source code for the official ROM. Perhaps he has somewhere, but if not then how about it Spencer?

Fixed BASIC for SIO boot loader - partial source.asm

Fixed BASIC for SIO boot loader - partial hex.hex

(modified Dr Baker's source to give hex output matching official ROM as far as this source goes, then applied fix)

Fixed BASIC ROM for SIO with code 0x0000 data 0x8000.hex

(complete BASIC ROM replacement including loader with fix for hanging problem)

The file "Fixed BASIC for SIO boot loader - partial source.asm" has the following notes in it to explain what I have done:

; This source code has come from:

; https://github.com/sbelectronics/rc2014/blob/master/asm/intsio.asm

;

; It is assumed this is the basis for the official RC2014 loader/driver for 

; MS BASIC with SIO module.

;

; I modified the SIO port addresses and assembled it. The resulting HEX file

; matches the official ROM until the last instruction in this source. The

; official ROM has additional code here.

;

; I've applied the fix to stop BASIC hanging waiting for a key press when

; running a variety of simple programs. The fix simply involves skipping some

; redundant code. For example:

;

; Grant's original CKINCHAR routine starts:

; CKINCHAR  LD A,(primaryIO)

;           CP 0

;           JR NZ,ckincharB

;

;           LD A,(serABufUsed)

;           CP $0

;           RET

;

; While official RC2014 ROM starts:

; CKINCHAR  CP 1                ; is A==1 

;           JR Z, CKINCHARB

;

;           LD A,(serBufUsed)

;           CP $0

;           RET

;

; It appears Dr Baker added a means to pass the SIO channel to this function,

; unfortunately MS BASIC does not provide this parameter. Thus when the function

; is called from BASIC and A happens to be 0x01 there is a problem.

;

; All modified lines are flagged with "<SCC>"

[Colin Little]

Thanks Steve, what an amazing amount of work ........ and files . Now need to get my head around them !!!!

[Spencer Owen]

On 4 April 2018 at 22:09, Steve Cousins <steve...@gmail.com> wrote:

(actual source code for official ROM - missing)

Spencer is the only one who can provide the actual source code for the official ROM. Perhaps he has somewhere, but if not then how about it Spencer?

The ROM that I supply with 32k BASIC and 56k BASIC for the SIO/2 board is pretty much based on Dr Scott Bakers code, which is itself largely based on Grant Searles code (which is itself based on Microsofts code... shoulders of giants and all that)

 The only change that I made was to the intsio.asm file to get the port numbers to line up with my SIO/2 board.  I'm pretty sure I used the same intsio.asm for both versions, but I've attached them here appended with _32k and _56k.

Hope that helps

Spencer

[Steve Cousins]

Hi Spencer

That ties up with what I found.

So why does the receive routine start with CP 1 followed by JR Z,RXB ? (code snip below)

;------------------------------------------------------------------------------

RXA:

                CP      1               ; is A==1 ?

                JR      Z, RXB

waitForChar:    LD       A,(serBufUsed)

                CP       $00

                JR       Z, waitForChar

The code jumps off if A is 1.

From my original report at the top of this thread: (note the value 1 in the second example)

This works fine:

10 POKE &H4000,2

20 PRINT ".";

30 GOTO 10

But this does not:

10 POKE &H4000,1

20 PRINT ".";

30 GOTO 10

So whenever receive is called and A happens to be 1, there is a problem.

Steve

[Spencer Owen]

Hi Steve,

The short answer is; I haven't got a clue :-)

The longer answer is explaining why I've not got a clue, and have only tweaked the bare minimum of the original code to get it working with my hardware, but I do really appreciate the work you've put in to track this down :-)

Cheers

Spencer 

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/de3282b7-ed4f-4b0e-b5b2-85b180584e33%40googlegroups.com.

[Steve Cousins]

Attached is Spencer's source code with the fix applied. I have not tested it, but am confident it is correct.

I have simply commented out the four redundant lines of code responsible for the problem. These are marked with "<SCC>" in the line comments, so should be easy to find.

There is a lot of redundant code in this source which could possibly cause other problems.

Steve

[Peter Willard]

I appreciate the fact that someone can look it over and determine what's redundant or a source of undesired behavior..

[David Brown]

Will you be updating the ROM images?  I'd love to reprogram my ROMs with official images.

Or at least I'd like to see the 32k and 56k BASIC HEX files more explicitly called out.

On Friday, April 6, 2018 at 9:09:26 AM UTC-7, Spencer Owen wrote:

[Spencer Owen]

Yes, I will be at some point.  Might be a week or two before I get the time to test it myself, but as long as it all checks out (I'm sure it does, based on what I've seen of Steves work!), I'll update my master image followed by the GitHub images.

Cheers

Spencer

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/23992cc9-26c3-43f6-ae26-9169284c4376%40googlegroups.com.