New firmware release (v1.9.0) available on GitHub

[TheHighNibble]

August 2021 Release - 2

This is a minor release that:

• integrates the AM9511 arithmetic processing unit (APU) simulation from Fred Weigel at https://github.com/ratboy666/am9511
• adds two (2) new CP/M disk images in support of the AM9511 APU
• adds a virtual paper tape reader and punch device (PTR:) to the desktop UI
• adds the paper tape device and a fall-through/follow-on feature to the HAL
• updates websockets to overflow gracefully and disconnect
• updates xybasic.hex ROM image to enable SAVE & LOAD from the PTR: paper tape device

See the release notes for more details.

[udo....@freenet.de]

"Sending to PTP: appends to the end of the tape and can cause an endless-loop if both reading (PTR:) and punching (PTP:) simultaneously."

Interesting. Way back then we played with the machines by creating a paper tape and used a patch to make an endless loop

from it. Then have the machine process that. Of course it would not just read the tape endless, it executes the instructions

on the tape.

[udo....@freenet.de]

I have updated my IMSAI 8080esp, went well and no issues.

Had a brief look the the paper tape stuff, looks OK, really great work Dave.

Gotta play some more with the new release ...

[udo....@freenet.de]

APU stuff looks good too, great work Fred and Dave.

[steve...@gmail.com]

I also updated my IMSAI 8080esp. Also went well with no issues not caused by myself. I played a lot with the paper tape, importing several BASIC programs written for my PiDP-8/i into the IMSAI for MS BASIC under CP/M. It is much, much easier than wrestling with cpmtools. Excellent work, all who contributed. It's a fantastic addition.

Thanks!

-- steve

[udo....@freenet.de]

On the PC emulation you don't have to wrestle with cpmtools if you don't want. The PC emulation has commands

'r' and 'w' and with that can transfer a file directly from/to the PC filesystem. No need to use cpmtools, xmodem ...

Quit easy to prepare disk images on the PC with that and transfer them to the ESP machine.

And yes, the paper tape is another easy way to get files in/out the machine, besides that it is fun and interesting

to use.

[villa...@gmail.com]

Thank you for another excellent add on. All working fine so far, yet to try it with HAL, maybe tomorrow after I clear up all the paper tape over the floor!!!

[steve...@gmail.com]

Udo,

Thanks for the advice, however I'm not on a PC. My host is a Raspberry Pi4 running Raspbian OS.

[udo....@freenet.de]

No problem. Z80pack is know to work fine on the Pi's too. You might need to reduce the framerate of the LED's,

by default it is 60fps, but configurable. Also you could build it without front panel and just use it for processing

disk images.

Here is an example what some others are doing on a Pi:

https://smpl.fyi/2021/08/running-cromemco-cdos-and-cromix-under-linux-headless/

[steve...@gmail.com]

Is there a maximum size for paper tapes? I'm trying to read a tape that's 23,413 bytes long (using Chromium on a Raspberry Pi) and it is crashing the web UI after I drag the file to the reader. Shorter tapes seem to work just fine.

[TheHighNibble]

Steve, not that I know of. But similarly I experienced a dropout after around 21K yesterday. I will investigate. 

[udo....@freenet.de]

Try to run the browser under a debugger, it will tell at least why the process gets terminated,

signal 11,

out of memory,

...

[Fred Weigel]

Udo

That doesn't work with modern browsers. Instead... open devtools for the browser.

That will allow access to the log and more (shift+control+j). The "browser under the

debugger" approach:

: fred@tara halfg $; ps ax | grep chrome-unstable/chrome | wc -l

15

is for a single chrome on my laptop -- with a single window/tab  The processes will come and

go.  I wouldn't know where to start!

Fred

[udo....@freenet.de]

fridtjof.ma...@gmail.com schrieb am Montag, 30. August 2021 um 14:16:34 UTC+2:

Udo

That doesn't work with modern browsers. Instead... open devtools for the browser.

That will allow access to the log and more (shift+control+j). The "browser under the

debugger" approach:

: fred@tara halfg $; ps ax | grep chrome-unstable/chrome | wc -l

15

is for a single chrome on my laptop -- with a single window/tab  The processes will come and

go.  I wouldn't know where to start!

Fred

That it is integrated somewhere in the GUI stuff doesn't really matter, there sure is a program chrome somewhere,

which you can execute also from the command line. And then you can also 'gdb chrome' and run it and see what

happens.

[TheHighNibble]

OK, i'm narrowing this down.

None of the code is "failing" with unexpected errors and there is no out of memory issue.

The websocket code on the IMSAI is getting an overflow condition, but I think the cause is actually how the browser behaves.

I am seeing a lot of discussion that Chrome has a timeout between 5-7 minutes when it decides to change the status of long running functions and this is probably causing the websocket to close.

This issue is happening repeatably at the 7 minute mark for me (after around 21K is sent).

I will do some more testing to confirm the root cause and try to identify a solution.

[TheHighNibble]

Well I thought so for a few hours, but it was not the problem. However, thinking that it was, did make me revise my JavaScript code and make it more efficient :-)

Turns out the problem was that the CP/M PIP command's buffering and disk writes would eventually run a little too long, and the websocket would overflow the message queue it was buffering into.

So, a very real problem for equipment of the era: a fast paper tape reader (50cps) with no flow control, overflowing the UART given the slow disk write speed of an overly large memory buffer!

Well, I cheated and gave the virtual UART a massive 256 byte buffer (too expensive in the late 1970's) and it solved the problem.

[udo....@freenet.de]

Quite funny, I was messing with such problem up into the 90s. My first 386 PC had a serial card using the very basic

Intel 8250 UART's, which would work halfway reliable at 9600 baud. Had to get a new card using the 16550 chips

that include a 16byte buffer, for getting any higher speeds working reliable. Was a must when I got that Zyxel modem

doing 16.8  Kbaud with their special protocol.

And now we still fiddling with such issues. Sure, the modern CPU's are fast enough for handling UART's at 115 Kbaud,

but the poor simulated 8080/Z80 of course cannot keep up without flow control.

[steve...@gmail.com]

In my case, I'm not even getting that far. The crash happens before the drag-and-drop is even complete. Here are my steps to re-create:

1) Imsai 8080esp is booted into CP/M with both TTY: and PTR: panes open in the Desktop (Chromium on a Raspberry Pi).

2) I drag the paper tape file onto the PTR: pane.

3) I am asked to confirm "Load cntdn2.pas [23413 bytes] into PTR: ?"

4) I click the "Ok" button to confirm.

5) After exactly 45 seconds delay I get a Chromium crash in the Desktop window saying, "Aw Snap! / Something went wrong displaying this web page / Error code 64000 / Learn more / Reload".

I can reload the Desktop window but then I am back to where I started. I'm never given the opportunity to even run PIP before the crash.

Again, I'm running Chromium browser on a Raspberry Pi 4 (4GB memory, latest release of PiOS). So it seems that PTR: won't work on Chromium with files bigger than about 15.5kb (the largest I was able to successfully load). I will try again later with Chrome on MacOS.

-- steve

[TheHighNibble]

Steve, thanks for clarifying.

I don’t know what separates Chromium from Chrome and I’m not in a position to test with Chromium on a Pi.

• Is it the latest version of Chromium
• Is Firefox available on the Pi and can you test with that

[steve...@gmail.com]

Yes, it's the latest version of Chromium.

In theory, Firefox is supposed to be available on the Pi but all of the different ways they suggested to install it didn't work. So, practically speaking, firefox appears to be unavailable for now.

Don't worry too much about it, tho. It's not a critical issue. I can still load smaller paper tapes (thanks!). And when I have a really big file to put on, I still have the CPMtools route available.

Best,

-- steve

[udo....@freenet.de]

Have you tried to read a file into CP/M directly with the 'r' command on the CP/M 2 disk?

File must be in upper case on the host filesystem for this to work. Would be interesting if

this also works with the Pi OS, I have none and am using only OSX, Linux and the like.

[Richard Deane]

On pi you could try a flatpak install of Firefox, then run command is something  like "flatpak run com.mozilla.firefox", but see examples for exact syntax. 

Have a look at flatpak.

Richard 

--
You received this message because you are subscribed to the Google Groups "IMSAI 8080esp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to imsai8080esp...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/imsai8080esp/eb6d0ca4-4c2c-48e2-bd06-79568b19eb7an%40googlegroups.com.

[villa...@gmail.com]

To try and assist: I have a Pi4 also  with Chromium which I don't usually use with my Imsai8080.

I can load the paper tape with e.g a 16.2k file, I get the WAIT message which I accept and PT loads OK

With a 23K file after accepting the WAIT message it eventually gives the 'AW Snap' message as per Steve's report.

So I'm basically seeing the same results as Steve .

Just before I post this I tried a 38K file on my windows10 m/c and after a 'page unresponsive' message it loaded ok (whether the data is correct not a clue !!!)

Colin

[udo....@freenet.de]

If you load really large tapes the JavaScript code will need some time to process that. The warning from

the web browser is harmless, it just thinks after some time that the script won't response anymore.

The loaded data should be correct however. If you use an Intel hex tape you can verify with reading

that in with CP/M pip, it will complain if the checksum is not correct.

[villa...@gmail.com]

Have you tried to read a file into CP/M directly with the 'r' command on the CP/M 2 disk?

File must be in upper case on the host filesystem for this to work. Would be interesting if

this also works with the Pi OS, I have none and am using only OSX, Linux and the like.

Udo: If I am doing this correctly - after reading a file (in CAPS) it shows it in the Directory but with 0 bytes.  What directory does R look in for the file to be read  - cannot use a path in the file name

W.COM gives 'Write error'

[udo....@freenet.de]

Usage of a path is not possible, the CP/M CCP cannot deal with this, so just plain filename and it must be

in upper case. Transfer is always in the current directory from where you started the emulation.

If it cannot write a file this could be caused by no write permission in the current directory.

[TheHighNibble]

A heads up on the issue stevet1958 raised:

I have significantly rewritten the internal JavaScript workings of the PTR: device on the webfrontend to optimise them and to remove latency as a tape being punched grows. The results are promising, and I expect this should solve the problems with Chromium on the rasPi:

• a drag-and-drop of a file from the local machine onto the PTR: now loads "instantaneously" eg. ~300K in under 1 second (previously 30K was taking 10+ seconds)
• tape punch speed now remains consistent as the tape grows (previously it was becoming noticeably degraded after ~10K  and continued to get worse as the tape length grew)
• to get a realistic tape punch speed you need to set the baud rate on the attached SIO port, values from 110 baud (11 cps) up to 4800 baud  (480cps) are all reasonable. If you set it to 0, "machine speed" you can punch a 30K tape in a few seconds - not very realistic - but if you are in a hurry, it works.
• I continue to throttle the paper tape read speed to 50cps as this is required not to overflow the speed that PIP can read data from the SIO @ 4MHz
• but even at this speed, to work for for tapes of > 20K in length I had to introduce a 256 byte buffer into the SIO/websocket code on the ESP32 - this is because PIP needs time to write data to disk, and this seems to take a variable amount of time (probably something to do with CP/M file extents), but there is no handshaking with the PTR: so a buffer is the solution
• 50cps tape read would have been considered fast and is what the Heathkit H10 could produce. Modern high-speed readers that can do 400cps might be fine when you are reading only to memory (like loading 8K BASIC from tape), but it's when data needs to be flushed from memory to disk that things can go wrong, and then you'd need an interface with hardware handshaking. Unfortunately websockets don't provide handshaking or backpressure and I'm not inspired to try and implement something just to see how fast we can push tape loads

So my next challenge is packaging these improvements for release or testing.

[TheHighNibble]

The patch release required to load tapes >20K and to improve the overall performance of the PTR:  is now available.

See https://groups.google.com/g/imsai8080esp/c/m1I0EqGZNM4/m/MRSzHn13BgAJ

stevet1958 : I'd particularly like to know if this fixes the problem with loading tapes under Chromium on the RasPi

Cheers,

Dave.

[villa...@gmail.com]

Thanks Dave - Well the good news is I ran through the procedure on my pi4 on Chromium, I can  get right through to the flashing cursor on Dazzler but can't move it (N M , .) keys or change colour i.e no keyboard activity.

Will check through my settings but PTR load, full 32k ! and PTP run perfectly smoothly.

I have also loaded Firefox on the Pi so will also try that for fun  when I can get the time.

[steve...@gmail.com]

Dave,

"stevet1958 : I'd particularly like to know if this fixes the problem with loading tapes under Chromium on the RasPi"

Yes, it appears to have fixed the problem. I was able to fully read a 23.4k tape. Thanks.

[John Kennedy]

I've been playing, and it's so neat. I love the fact that extra virtual features can be added in this way.