RC2014 CP/M

[Mitch Lalovie]

Hello All.

Please find attached CP/M HEX files for the RC2014.
CP/M sources came from Grant Searle web site.
Following is required:
RC 2014 needs full 64K RAM and some means of
preloading monitor.bin in RAM.
CP/M bios expects to see CF flash storage
please see http://searle.hostei.com/grant/cpm/index.html#InstallingCPM

This version dos not require SIO chip it should work with ACIA on port $81 and $81,
in IM1.


MITCH.

[Mitch Lalovie]

I meant on port $80 and $81.

MITCH.

[Scott Lawrence]

Awesome. I'm gonna have to look into this shortly! :D

I've recently redirected my efforts from my serial-bus experimentation and SD card drive (at $C0, $C1) into a hardware-less software-only mass storage option.

Yes.  You read that right. No additional hardware to get a mass storage solution.  I'm working it out first in my emulator, then I'll be porting the software into PiGFX and my LlamaTerminal application...  I figure we already have a huge SD card on the PiGFX or a huge amount of storage on a host computer being used as a terminal... might as well use that!

The basic idea is that it uses a kind of "backchannel" over your console connection...  like a X/Y/Zmodem kind of thing.  So all of the mass storage happens on your host system: desktop computer for emulation/LlamaTerminal, and your Raspberry Pi Zero for the PiGFX version.  The cool thing about this, is that it can also inject data as if you were typing it in.  So the "boot loader" will be a few stages:

Stage 1: small BASIC program (based on the code provided by Filippo) with a simple asm code to read HEX will be "typed" in, and run.

Stage 2: the asm code downloaded will run, which provides full HEX file parsing, then the HEX file will be loaded natively though the backchannel

Stage 3: That loaded in code will be run.

All of this happening without any additional ROM to be burned!

With a simple hack of a 32k module and the ROM module, you can also then switch it into a clean 64k RAM system, and use the entire thing for loaded in programs.... or CP/M.   

I am also planning on writing a new BIOS for CP/M that uses this backchannel for disk IO... which brings up another feature of the system.  The backchannel supports "typing" in text, the standard file-based IO as well as sector-based IO.  The sector IO will operate on virtual disks, where each sector is its own file on the host... it kind of translates disk/track/sector to individual files.  These complete disk heirarchies should be sharable.  I also forsee some CP/M applications that can access the file-io on the host, and copy (pip) the files back and forth... perhaps even support for existing disk images would be workable... for maximum compatibility.  Should be pretty exciting to get going!

I just realized that the backchannel could also support multiple streams, so you could set up a printer as well, or perhaps write some code that takes the CP/M printouts and generates a PDF from them, etc.  That could be neat!

Anyway... stuff to do!

-s

--
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/780f0cf9-82a3-41c2-ab0a-482946c445f0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Scott Lawrence
yor...@gmail.com

[Ben Chong]

On Thursday, February 16, 2017 at 2:10:03 PM UTC-8, Mitch Lalovie wrote:

please see http://searle.hostei.com/grant/cpm/index.html#InstallingCPM

This link doesn't seem to work.

I've not been able to get anything from searle.hostei.com for the past couple of weeks.

I'm coming from a US-based IP address, in case that makes a difference...

 

[Spencer Owen]

Hi Ben,

Grants site is working fine from here, both from a regular UK IP address and also over the cellular network.  It's also been fine whenever I've tried to access it over the last few weeks too.

Has anybody else in the US (or elsewhere for that matter) had any issues?

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/92c9830a-6a94-4d8c-b5a6-fb6565acb458%40googlegroups.com.

[Ed Thierbach]

I have in the past, maybe a couple of months ago, but no problem now.

-Ed-

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAO93Ptfj4fZitg5Xq0Xr-G-vQbpFP-_D5FANuW5eJ2dg1AusOw%40mail.gmail.com.

[Mitch Lalovie]

Hello Scott.


That is a good news, I have not used PiGFX module at all,
but from what I have observed so far, it is very easy to
flood ACIA/Z80 unless there is delay on TX(host side).
On minicom lowest delay is 1 millisecond and that slows
transfer speed from host to RC2014 considerably.
I did not do any experiments with the delay treshold
that would indicate what is the lowest acceptable delay.


Regards,


MITCH.

[phillip.stevens]

Just on the point of overloading the ACIA.

Grant's I/O routines are simple by design. And are very slow. As a non-expert I was able to get them much more efficient, without much trouble.

Also the HexLoadr program can be streamlined too.

I can upload HEX at line rate with Linux 'cat'. With the HexLoadr ROM. So the rc2014 is not the issue IMHO.

Phillip

[Ben Chong]

ACIA overloading:

I hit this problem yesterday by the simple exercise of copying and pasting the mandelbrot program on the terminal emulator (Serial on Mac). I had to use a 25ms line delay.

Spencer, is the default ROM image on the RC2014 using Grant's original 32K BASIC+Init or Filippo's (on github)?

Grant's original ACIA code actually runs a 64 byte buffer, whereas Filippo's doesn't (at least not in the asm file). Unfortunately, while it looks like RTS is wired up, Grant's code basically dumps any overflow characters once the buffer is full. One optimization might be to run a high/low watermark approach and try to toggle RTS appropriately.

Of course, I may be misunderstanding the point of RTS...

[phillip.stevens]

Ben,

 

ACIA overloading:

I hit this problem yesterday by the simple exercise of copying and pasting the mandelbrot program on the terminal emulator (Serial on Mac). I had to use a 25ms line delay.

Yes, I hit this issue straight up too. It is a combination of short buffer and inefficient code in the Searle ACIA code.

Also, Nascom Basic is quite slow too because it is an interpreter which does (really) quite a lot with each character it receives.

The ACIA and the RC2014 CPU are not the problem. The RC2014 is running at 7.3728MHz.., nearly 4x older Z80 systems.

Spencer, is the default ROM image on the RC2014 using Grant's original 32K BASIC+Init or Filippo's (on github)?

IMHO, Spencer is using the Searle code, as this is the proven default that has been there since the beginning...

AFAIK, Filippo hasn't done any work on the RC2014 ACIA. He's been mainly been working on PIGFX and did the first hexload program.

OTOH, I've been looking at the Nacom Basic ACIA code quite intensely, because of a side project that required writing serial code from scratch.

 

Grant's original ACIA code actually runs a 64 byte buffer, whereas Filippo's doesn't (at least not in the asm file). Unfortunately, while it looks like RTS is wired up, Grant's code basically dumps any overflow characters once the buffer is full. One optimization might be to run a high/low watermark approach and try to toggle RTS appropriately.

I'm not sure which asm code you're looking at, but I set up my ACIA code with a 256 Byte Rx buffer and a 15 Byte Tx buffer and left the Searle RTS code in place.

But note I don't think hardware handshaking using the FTDI USB interface on the RC2014 works. The FTDI interface needs to be configured to respect RTS.

The RTS code is simply a waste of space, in this situation.

Hijacking this CP/M thread, but my default is to use this 32k Basic with optimised Rx buffer handling with integrated HexLoadr capability.

This lets me simply cat Intel Hex assembler to my RC2014, like in this video. That's fast enough for me.

cat myprogram.hex > /dev/ttyUSB0

With Nascom Basic, you're always going to have to use a slowprint.py option, because of the amount of interpretation work that it has to do.

Or just use the biggest sensible Rx buffer possible, to allow you to copy/paste as much Basic as you can per cycle.

[Spencer Owen]

 

Spencer, is the default ROM image on the RC2014 using Grant's original 32K BASIC+Init or Filippo's (on github)?

IMHO, Spencer is using the Searle code, as this is the proven default that has been there since the beginning...

Ah, sorry, I missed this bit when the original email came in.  Yes, it's the original 32K BASIC from Grant Searles website that I ship with the RC2014.

I know some people have improved on it in various ways (such as the ACIA handling discussed here), but for now at least, I know this is a safe and reliable way to get people up and running.  And there's a bit of consistency that close to 600 RC2014 owners can have just by setting their jumpers back to 000 :-)

Spencer

[Scott Lawrence]

600?  Wow!  Nice job, Spencer! :D

Hmm... maybe there is a market for my rom/ram switching card. hmmm

-s

--
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/CAO93Ptd8WvKR79YxG8mUhowLJ5tT%2BwK%3DKEssLOGWoSi6-SFWZQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Scott Lawrence
yor...@gmail.com

[Ed Thierbach]

Hmm... maybe there is a market for my rom/ram switching card. hmmm

I'd buy one, if it was offered as a complete kit or assembled and tested.

Spencer, did you ever think you'd sell 600 of these?

-Ed-

[Scott Lawrence]

I should really do it.  Right now it's a hack across multiple stock cards.  I wanted to make it as a changelist of "proper" RC2014 cards, so that it was easily reproducable, but I'm realizing now that I'm the only one silly enough to do it.

It's a hack in 3 parts:

1. It uses bit '0' of the digital output board to toggle between ROM and RAM mode for the bottom $0000-$7fff region.  That bit output is wired up to one of the unused lines of the data bus.

2. the ROM board is modified, using a previously unused 74xxx gate, to look at this bit, and enable the ROM output if that data line is LOW.

3. an additional RAM board is also configured to be at $0000-$7fff (instead of the stock $8000-$ffff), and writes to it are ALWAYS enabled.  Reads are toggled by that same bit, and if the bit is HIGH, then reads come from the RAM.

This could easily be shoved onto one single board, replacing the ROM board, and providing the ROM socket, $0000 RAM and the switching port.  Perhaps this is my first KiCad project!

So, since the RAM is always there, you can (and I have) copy the entire ROM to RAM by a loop of:

10 for A = 0 to 8192

20 poke A, peek( A )

30 next A

which reads the value and seemingly writes it to the same location, but in actuality. it copies the content from the ROM to the RAM.

Then I switch to RAM mode:

40 out 0, 1

...and bam. running BASIC out of RAM, from a full 64k of RAM.

I've tested it by picking a location, like 8000 and writing to it.  If I read back the original value, I know it's ROM mode, if I read back something else, I know it's RAM mode. (and of course restore the value just in case.)  Like so:

50 A = peek( 8000 )

60 if A > 128 then goto 100

70 N = 111

80 goto 110

100 N = 222

110 poke 8000, N

120 T = peek( 8000 )

130 if T = A goto 200

140 print "RAM mode!"

150 poke 8000, A

160 END

200 print "ROM mode!" 

210 END

I've got this working in the "rc2014LL" project in my emulator, as well as on "real" hardware.  The changelist mods are available in this pdf:

https://github.com/BleuLlama/z80-machine/blob/master/rc2014LL/Docs/RC2014%20Switchable%20ROM.pdf

Although some of the info there, the mods WRT the reset line didn't work.  I really should make my own board for this. :D

...The great thing is, now that I'm doing my Mass-Storage-Via-Terminal method (I need a name for this), no additional modifications are needed to get CP/M running on the thing! (of course with a new BIOS that uses the Terminal storage system.

Right now, I have handlers for the terminal to type in a program from disk, or really any series of data.  Currently, for testing, i type:  [esc][}]type test.bas[ctrl-c] and it "types in" "test.bas" to the RC2014, with delayed buffering so it doesn't overrun the buffer.  This could (and will be) easily expanded to boot up the HEX Loader code, and inject the proper values into the DATA statement from a specified file, and run it, to kickstart a HEX loader.  

From there, I will also be adding in a check to see if it reads the BASIC startup sequence, and then auto-types in a script from disk... 

So the sequence of events for booting CP/M will be:

1. RC2014 powers on, Terminal Filter sees the startup

2. Filter "types in" autorun.txt, which contains the BASIC HEX loader, types "run"

3. BASIC HEX loader runs, which loads in CP/M BIOS, CPP, BDOS into RAM

4. Turn off ROM

5. Reset to start CP/M

all happening automagically!

(in progress)

-s 

-s

--
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/CA%2Bfa_sicCfipp%2Bamj4OXvjx%2ByrWp%2BqZJzZGUJAWW4Kn8Oc_JHQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Scott Lawrence
yor...@gmail.com

[Spencer Owen]

Normally I don't pre-announce new boards, but I thought maybe this was a good time to mention the new super duper ROM board that I've been testing all weekend.

Spoiler: It needs a small revision to the current PCB, so that'll be about 10 days before it's available on Tindie.

The main advantage of this one is that it can take various sizes of ROM from the 2716 up to 27C512.  The page size can be 2k, 4k, 8k, 16k or 32k - so, depending on the size of image you need, you can have up to 32 images on a single chip.  Or mix & match different sizes.

It also works with the 64k RAM Module so the ROM can be paged out and the RAM paged in.  I've got a short assembly code routing working that can get BASIC running from RAM in just over a second.  Also, with the files that Mitch attached at the beginning of this thread, it can run CP/M - Well, nearly.  I've got some Compact Flash sockets on order, so I should have this working by the end of the week.

Oh, and it takes ZIF sockets, so easy to swap ROMs if you want to :-)

Spencer

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAKD5ztbZSvdOUHBV7Dp7JhKW2bLc82CJKXT252iQUdoC14EaZw%40mail.gmail.com.

[Spencer Owen]

Spencer, did you ever think you'd sell 600 of these?

-Ed-

Hi Ed,

No!  I didn't think I would sell even 10 of them until I'd sold 9.  Then I didn't think I'd sell 100 until I'd sold 99.  I'm not quite up to 600 yet (just over 590 I think), so until I've sold 599 I still don't think I'll sell 600 :-)

Spencer - looking forward to a nice round 1024 sales one day ;-) 

[Ben Chong]

On Tuesday, February 21, 2017 at 7:11:58 AM UTC-8, Spencer Owen wrote:

Normally I don't pre-announce new boards, but I thought maybe this was a good time to mention the new super duper ROM board that I've been testing all weekend.

Perhaps also make the addressing selectable so that it can slot between the 8K BASIC ROM and the 32KB RAM? 

Like an expansion ROM...

I can then keep the BASIC ROM on my mini and run an alternative monitor etc in the expansion ROM space. All without digging up that BASIC ROM multiple times and ruining the socket...

 

[Spencer Owen]

Hmmm... I hadn't thought of that, but I think with the right jumper selection that this new board will be able to do that.

I'm going to have to sit down with a pen and paper to work it out though.

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/8cefd855-436e-4b05-89e0-85bc5c63c58f%40googlegroups.com.