An editor/assembler for Searle Z80 & the basic 32k RC2014 Mini/Micro

[Phil G]

Just checking for interest, I've done a port of 'Zen' which runs on these basic 32k boards without storage, Zen is entirely memory-based, so the editor-assembler, your source code, symbol table and the object code produced all reside in RAM which makes it ideal for a small system without disk storage. Just as with BASIC, listings can be saved with a Teraterm capture, and reloaded with 'paste' or 'file,send' .

It works really well and allows the full development cycle on the Z80 itself. Its very much like the ZEAP editor/assembler I had on my Nascom-1 back in 1978. Of course I've CP/M systems here that can do the whole cycle with ease and my favourite PC cross-assemblers but this is particularly interesting as its on such a basic machine and totally self-contained.

Zen readily assembles itself which is handy for edits, the only stipulation is that you have to bear in mind where everything is in memory.

The manual is short & sweet, its easy to memorise, there are very few commands.

We dont see many Mini/Micro posts here so I dont know if there is any interest in this, if not, no problem, if there is let me know & I'll post details.

Cheers

Phil_G

[Phillip Stevens]

Phil,

at the risk of opening a can of worms, I can see an application to add Zen as an application for MS Basic.

In the simple case, Zen can itself be a HEX file that is loaded (using HLOAD) into memory (from 0x8400), which then takes over from BASIC (using the established RSTs for communication). Zen can then load (using its own version of HLOAD), edit, and assemble its own programs. I understand from the manual it only takes 14 pages (3.5kB) of memory, so quite large programs could be built (from 0x9800 to 0xFFFF).

The next level of integration would be to include a ZEN key word into Basic to launch the Zen application from an upper 8kB ROM (not sure whether the Mini supports larger than 8kB ROMs, perhaps S1 would need to be patched to A13), and give it access to the full free RAM (0x8400 to 0xFFFF).

In both cases it would be very nice to add a keyword to Zen to set up the Basic USR(x) command (like HLOAD does) and return to Basic, to allow (fast) assembly subroutines to be called from Basic programs.

Cheers, Phillip

[Phillip Stevens]

Note to self. Don’t try to add in hex in the morning.

> I understand from the manual it only takes 14 pages (3.5kB) of memory, so quite large programs could be built (from 0x9800 to 0xFFFF).

It should be 0x9200 to 0xFFFF is available.

P.

[Phil G]

Sorry forgot to say, Zen works in conjunction with my monitor, see the Retro Z80 page on http://philg.uk

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/tQbiZ61OrA4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/21a43ae8-f323-4737-990a-cf17210c5119n%40googlegroups.com.

[Spencer Owen]

On Fri, 3 Mar 2023 at 00:10, 'Phil G' via RC2014-Z80 <rc201...@googlegroups.com> wrote:

We dont see many Mini/Micro posts here so I dont know if there is any interest in this, if not, no problem, if there is let me know & I'll post details.

Interestingly, there are more Micro/Mini/Classic II (ie 32k Grant Searle based designs) sold than the bigger Pro/Zed machines, although I know a lot more posts on here revolve more around CP/M, storage and more advanced stuff.  Quite a few people upgrade their Mini or Classic II to CP/M, but I'm sure there's still a lot of users of the 32k machines.

I suspect that Micro/Mini/Classic owners just get on and build their kit, write some BASIC programs, maybe do some Z80 stuff in SCM, and don't really have a need to ask many questions or share their experiences.  But, yes, I would also love to know if the 32k users out there would be interested in this.

Spencer 

[Phillip Stevens]

Phil,

do you have a link to the Zen source code? I've done a quick search, but I'm only coming up with the User Manual.

I'd like to try to build Zen as a loadable application for MS Basic on the Micro/Mini/Classic ][.

On Friday, 3 March 2023, Phil G wrote:

Sorry forgot to say, Zen works in conjunction with my monitor, see the Retro Z80 page on http://philg.uk

In the simple case, Zen can itself be a HEX file that is loaded (using HLOAD) into memory (from 0x8400), which then takes over from BASIC (using the established RSTs for communication). Zen can then load (using its own version of HLOAD), edit, and assemble its own programs. I understand from the manual it only takes 14 pages (3.5kB) of memory, so quite large programs could be built (from 0x9200 to 0xFFFF).

In both cases it would be very nice to add a keyword to Zen to set up the Basic USR(x) command (like HLOAD does) and return to Basic, to allow (fast) assembly subroutines to be called from Basic programs.

Just to note that as an application loaded by MS Basic, it only needs to return via ABPASS to exit cleanly to Basic, and allow the creation of assembly subroutines for Basic programs. This makes things quite easy I hope.

Cheers, Phillip

[Phil G]

Hi Phillip, you havent even seen my project yet and you want to modify it?   :-)

What you're describing is done already, if you remember I added a monitor to the 8k Nascom BASIC and Zen integrates with that, its only a small monitor but very useful and includes an Intel Hex loader. The monitor document describes USR(x) integration.  You can warm-switch between Zen and the monitor with one command.   

Beware that Zen isnt straightforward (no comments, assumed pointer MSB's and lots of stack manipulation etc) and would be easy to break so I would humbly suggest studying the code a while before modifying it  :)      Its on http://philg.uk and if anyone would like to try Zen as posted I'd love to hear how you get on!  :-)

Cheers

Phil

[Phillip Stevens]

On Saturday, 4 March 2023, Phil G wrote:

Beware that Zen isnt straightforward (no comments, assumed pointer MSB's and lots of stack manipulation etc) and would be easy to break so I would humbly suggest studying the code a while before modifying it  :)   Its on http://philg.uk and if anyone would like to try Zen as posted I'd love to hear how you get on!  :-)

You've definitely set an intelligence test to access Zen. ;-)

I've searched your entire site, also downloaded all of the zip files, and I've asked Google to search your entire site too.

There's no reference to Zen that we can find.

Help needed.

[Mark T]

On this page, not very well hidden:)

http://www.mccrash-racing.co.uk/philg/retro/retro.htm

[Phillip Stevens]

I guess we just failed the intelligence test. ;-(

[Phillip Stevens]

On Saturday, 4 March 2023, Phil G wrote:

Beware that Zen isn't straightforward (no comments, assumed pointer MSB's and lots of stack manipulation etc) and would be easy to break so I would humbly suggest studying the code a while before modifying it  :)   Its on http://philg.uk and if anyone would like to try Zen as posted I'd love to hear how you get on!  :-)

I've had some fun tonight playing with the Zen code.

Works as expected, and I (imho) think it is a very worthwhile addition to RC2014 options.

Don't know if we have a rating scheme... perhaps there should be one for RC2014 applications? Spencer?

I changed the QUIT routine to get it to jump to ABPASS rather than to your monitor base address. This allows the RC2014 Basic hexload program to load Zen, and therefore allows usage for people even without a ROM burner (i.e. even without any monitor) to use it. I did that by patching the address and checksum in the hex file directly, which is a PITA.

So then I wanted to use Zen to assemble a new version of itself, by uploading the source assembly. (I realise that this is not the right way to do it, rather assemble in place would be the right way). But when I uploaded the complete file, of course it was too large. I noted that your SOF and EOF are set 0x1800 after the ORG, and the program only needs less than 0x1000, so I changed these in the hex file too. Now there is enough space to upload a second copy of Zen, but the assembly fails after about 320 lines.

Is there a reason to leave 0x0800 Bytes free between the end of the program and the SOF?

Also just FYI, if you don't need to leave space for the hexload Basic program or for other Basic programs (i.e. not writing a subroutine in assembly), then the origin could be moved down from the 0x9000 default. I generally use 0x8400 as an alternative origin (needed for Startrek, for example), which provides a few more bytes for C or assembly programs.

Cheers, Phillip

[Phil G]

>>𝐼𝑠 𝑡ℎ𝑒𝑟𝑒 𝑎 𝑟𝑒𝑎𝑠𝑜𝑛 𝑡𝑜 𝑙𝑒𝑎𝑣𝑒 0𝑥0800 𝐵𝑦𝑡𝑒𝑠 𝑓𝑟𝑒𝑒 𝑏𝑒𝑡𝑤𝑒𝑒𝑛 𝑡ℎ𝑒 𝑒𝑛𝑑 𝑜𝑓 𝑡ℎ𝑒 𝑝𝑟𝑜𝑔𝑟𝑎𝑚 𝑎𝑛𝑑 𝑡ℎ𝑒 𝑆𝑂𝐹?

Yes, the symbol table is built between the end of Zen and the start of source, the doc explains.  Zen cant assemble itself in 32k,  not enough room even if ORG'd just after the keyboard buffer, I use a  56k Grant Searle for dev (Zen assembling Zen) and I have a couple of 32k's I hexload to.

[Phil G]

Instead of changing stuff to return to basic why not install the monitor version of Nascom basic, it detracts nothing at all as it uses otherwise empty space, there are no disadvantages - admittedly its not romwbw in only 600 bytes but it is very useful and runs "as well as" basic rather than "instead of" like SCM etc,, its not 'paged in', its there whenever Nascom basic is there and obeys the basic 'monitor' command. Its far more effective as a monitor than 600 bytes of empty eprom space!

It has Spencers approval though he's not yet offered the update, anyway, I've added a third build to the zip for you, this one ORG'd at 8400H.

Given your previous difficulties you might need to add a parameter to the link to force a cache reload, a simple ?a=7 or similar url postfix will suffice.

Even loading at 8400H (as low as poss in a 32k system), the source for Zen itself doesnt leave enough room for the symbol table and object code.

Its not a limitation of Zen or the port, Zen is quite a large source file for a memory-based system, its a minimal dev system especially on minimal 32k hardware after all.

Back in the days of the Video Genie (also 32k) I used Zen exclusively and I like its self-contained simplicity.  It feels like you're putting a negative slant on the project by trying to squeeze a quart into a pint pot?

Files on http://philg.uk  (including your org 8400H version)    :-)

Cheers 

Phil

[Le Fauve]

On Friday, March 3, 2023 at 10:10:17 AM UTC+10 Phil G wrote:

Just checking for interest, I've done a port of 'Zen' which runs on these basic 32k boards without storage, Zen is entirely memory-based, so the editor-assembler, your source code, symbol table and the object code produced all reside in RAM which makes it ideal for a small system without disk storage. Just as with BASIC, listings can be saved with a Teraterm capture, and reloaded with 'paste' or 'file,send' .

I'm definitely interested.

I didn't knew your BASIC with monitor rom, but I'll try to burn it first!

On Friday, March 3, 2023 at 9:34:06 PM UTC+10 Spencer Owen wrote:

Interestingly, there are more Micro/Mini/Classic II (ie 32k Grant Searle based designs) sold than the bigger Pro/Zed machines, although I know a lot more posts on here revolve more around CP/M, storage and more advanced stuff.  Quite a few people upgrade their Mini or Classic II to CP/M, but I'm sure there's still a lot of users of the 32k machines.

Really? Since I read this group I feel like I'm the last one not using CP/M on the RC2014 :o)

Perhaps I should share my ROM selector add-on for the 8KB ROM board? (I really assumed no-one would be interested in this; would anyone like to be able to switch rom by a long press on RESET instead of dealing with the jumpers?)

Cheers,

Eric

[Phillip Stevens]

On Sunday, 5 March 2023, Phil G wrote:

Back in the days of the Video Genie (also 32k) I used Zen exclusively and I like its self-contained simplicity.  It feels like you're putting a negative slant on the project by trying to squeeze a quart into a pint pot?

Phil,

please don't get me wrong. Based on my small experience with Zen, I see it fulfils a very useful purpose. With Zen it is possible to write and importantly maintain assembly language programs using the RC2014 Classic ][ 32kB platform. I love that. It is a real addition of capability to an already capable machine.

There is and was no negative spin on the project intended. Sorry if I came over that way.

Instead of changing stuff to return to basic why not install the monitor version of Nascom Basic,

It is very simple. The vast majority of RC2014 Classic / Mini / Micro owners do not have any ROM burner. Nor do they intend to get one. Therefore, requiring them to purchase a ROM burner to burn your monitor before using Zen will produce... "crickets" ...in response. So, if you want to meet the market (as they say), IMHO you need to make Zen a well behaved MS Basic application, using DEINT parameter passing and ABPASS to return with the Basic stack restored to the entry condition, that can be uploaded using hexload (or alternatively work with SCM and ignore Basic entirely).

...it detracts nothing at all as it uses otherwise empty space, there are no disadvantages

Apart from creating a very limited potential user base noted above, for me there is a laundry list of disadvantages to using the standard Searle MS Basic 4.7, that I will not present here (except to mention the persistent serial receive over-run).

 

...admittedly its not romwbw in only 600 bytes but it is very useful and runs "as well as" basic rather than "instead of" like SCM etc,, its not 'paged in', its there whenever Nascom basic is there and obeys the basic 'monitor' command. It's far more effective as a monitor than 600 bytes of empty eprom space!

Being honest (and this is just my opinion), there is no use case for a monitor for the RC2014 Classic / Mini / Micro, whether it is 600 Bytes or 8 kBytes, when there is very powerful high level language command line interpreter already present, i.e. MS Basic. IMHO, there is no use case that a monitor of any complexity can resolve, that MS Basic can't do equally well and do it with better maintainability.

The exception to the above being writing and maintaining assembly language programs or subroutines, which you've neatly resolved with Zen.

Files on http://philg.uk  (including your org 8400H version)    :-)

Thank you.

Cheers, Phillip

[Phil G]

>>𝑡ℎ𝑒𝑟𝑒 𝑖𝑠 𝑛𝑜 𝑢𝑠𝑒 𝑐𝑎𝑠𝑒 𝑓𝑜𝑟 𝑎 𝑚𝑜𝑛𝑖𝑡𝑜𝑟 
I'm sorry but this is just so utterly blinkered - I dont want to get into it, we're going to have to agree to differ.  

Personally I cant speak on behalf of "the vast majority of users" and I have no knowledge of the equipment they have.

If anyone in the UK wants a rom burning I will happily do that FoC.  I do similar things for the R/C community, 

I'm used to doing these things for the pleasure of helping people  :-)

I checked the symbol table size after assembling Zen in Zen and its 300 hex bytes so you could juggle memory and maybe squeeze everything into 32k.

In my naivety I wasnt expecting this kind of response so I'm going to quietly get on with my own projects and leave the forum to the BASIC experts.

If by chance anyone is interested I can be contacted by email - I'm not hard to find :-)

Cheers

Phil

[Spencer Owen]

Hi Eric

Perhaps I should share my ROM selector add-on for the 8KB ROM board? (I really assumed no-one would be interested in this; would anyone like to be able to switch rom by a long press on RESET instead of dealing with the jumpers?)

I would be very interested in seeing that.  I do have my own solution involving an up/down hex switch for testing purposes, but it certainly isn't elegant!  If you could share any info in a new thread that would be great.

Spencer 

[Spencer Owen]

On Sat, 4 Mar 2023 at 14:11, 'Phil G' via RC2014-Z80 <rc201...@googlegroups.com> wrote:

Instead of changing stuff to return to basic why not install the monitor version of Nascom basic, it detracts nothing at all as it uses otherwise empty space, there are no disadvantages - admittedly its not romwbw in only 600 bytes but it is very useful and runs "as well as" basic rather than "instead of" like SCM etc,, its not 'paged in', its there whenever Nascom basic is there and obeys the basic 'monitor' command. Its far more effective as a monitor than 600 bytes of empty eprom space!

It has Spencers approval though he's not yet offered the update, anyway, I've added a third build to the zip for you, this one ORG'd at 8400H.

Well, I guess the cat is out of the bag, but since the start of this year, most RC2014 Micro and RC2014 Classic II kits have shipped with 32k BASIC that includes Phil Gs Monitor.

I "stealth launched" it, on the basis that it doesn't detract from what anybody expects to be able to use on their Micro or Classic II.  I wondered if anybody would discover MONITOR as an Easter Egg, or if not, I would wait until I thought that there were enough machines out there with it already that I could just mention it and most people could just use it if they wanted to.

But, hey, if you have an RC2014 Micro or RC2014 Classic II and the ROM sticker has the R000009 with a blue highligher through it, then you should be able to type MONITOR and start using it :-)  Sorry, RC2014 Mini owners, but I'll be updating the Mini ROM shortly.

It is a very handy addition to BASIC, and doesn't need any jumpers changing to access it.   

By the sounds of things, Zen would also be a very nice addition to the ROM on those machines, and probably the RC2014 Pro too.  I haven't had a chance to give this a test yet, although I would be interested in any feedback from those that have.

Cheers

Spencer

[Phil G]

Ah... really sorry Spencer I didnt realise...        but many thanks for doing that :)

[Spencer Owen]

Just following on from my earlier post about the enhanced 32k BASIC that includes Phils MONITOR, I have put the ROM files up on GitHub for the RC2014 Micro (R9.R90R9plus) and Classic II (R0000009plus) https://github.com/RC2014Z80/RC2014/tree/master/ROMs/Factory

These are for the 39SF010 chips which are a 128k Flash chip, so if you have a Micro or Classic II with one of those but without the MONITOR then you can reprogram the chip you currently have.  

If you have an older 27C512 ROM then you will need to just take the first 8k of one of those images and burn it to a blank 8k page on your existing ROM.  Exactly how you do that will depend on your programmer and software.  If you're in need with assistance there, then maybe start a new thread with details of your current ROM, programmer, software and OS, and I'm sure we can help you out there.

Spencer

[S P Dixon]

This has been a really interesting thread. Talk of Zen as an assembler / code editor that would run on the classic machine really grabbed my interest.

I wasn't aware of Phil's monitor, or that Spencer had already packaged it with BASIC, so I've grabbed the updated ROM image and I've managed to burn that to an empty slot in my banked ROM and I enjoy the fact that I can jump straight into the monitor at startup, or from BASIC using the monitor command. 

As mentioned in the discussion, Phil's port of Zen is ram-based, but it's obviously easy to paste that in using one of the monitors. That's quite an experience and there's a bit of a learning curve getting to grips with the editing! But this afternoon I've been able to assemble some source using Zen. (I got as far as displaying the assembled hex in the terminal - can it deploy the assembled program into memory starting at the ORG address? That didn't seem to happen for me but it's very possible I've got something wrong, or just haven't learned how to do that. I quit back to the monitor and keyed and ran my assembled program there!! Maybe that's what you had to do in 1979, let me know if I'm missing something simple.)

There was also a question about the use of the 32k RC2014 vs the bigger configurations with storage. I suppose it's a natural progression  - I added the CP/M kit to my original Classic, and then added modules and eventually a Pro backplane. I then rebuilt my Classic , because although I mostly use my Pro / CP/M, I *LOVE* using my Classic as I have done this afternoon (At EMF camp I did a 'live coding' demo of some 8x8 matrix animations using just SCM to assemble on a classic. Getting back to the bare bones of Z80, ROM, RAM, Serial i/o really lights my fire.)

The reason for this message is mostly to thank Phil G. I wasn't fully aware of his monitor and port of Zen but I'm glad I have all of that now. Thanks Phil!

--
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 view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/0a9a0783-5b90-4a83-b4d8-1fc40e01a5d9n%40googlegroups.com.

[Phil G]

Aw, thanks!

You need a 'LOAD' statement which tells Zen where to put the object code - this is the key to running on a  small system - code can be ORG's somewhere and LOAD'ed somewhere else. Or in the same place.

Say you need your final code located where Zen currently resides. Obviously you cant let it overwrite object code over the assembler whilst its assembling so you ORG it where its eventually going, LOAD it somewhere free, go into the monitor and copy from the temporary area to its final location (overwriting Zen, but thats no longer a problem after a successful assembly!) .   The manual is worth reading, its very short and covers all this, you soon get used to it. Or 're-used' to it from my Genie days!

The zip has a couple of variations of an Intel Hex saver as example source, this is actually from my Genie stash, load them up and play, you get the idea, copy & paste into notepad from the terminal buffer, usual thing as with basic.

Cheers & thanks again!

Phil

[S P Dixon]

aha! LOAD. Thank you.   I've had the manual open from the start, without it I wouldn't have got as far as I did. I guess I glossed over the pseudo-opes because I'm familiar with org, defb etc, 

Shiela

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/a7f26632-d4b9-46c6-8df0-16eabd590becn%40googlegroups.com.

[Le Fauve]

On Sunday, March 5, 2023 at 10:33:54 PM UTC+10 Spencer Owen wrote:

Hi Eric

I would be very interested in seeing that.  I do have my own solution involving an up/down hex switch for testing purposes, but it certainly isn't elegant!  If you could share any info in a new thread that would be great.

Thanks Spencer!

 I just posted a new thread,  but my solution only emulates 3 jumpers, which seems a lot less than the one you're using.

As for the "elegance", I kind of cheated a little by using a modern MCU :o), but it does work and I wouldn't have been able to make something that small using another solution.

Cheers,

Eric

[Bill Shen]

Zen is a fun program!

I ported it to two of my Z80 SBC.  I only need to patch three locations:
* serial-out function is RST 08, so patch in the jump address for my monitor's serial output routine.
* serial-in function is RST10, so patch in my monitor's serial input routine
* "Q" command points to 0x1DC0, thus patch to my monitor's entry.

I like zen's ability to assemble new zen with existing zen.  

It is a nice program for a bare minimal Z80 SBC like ZoRC
  Bill

[Phil G]

I've updated Zen, if anyone's still interested please download a fresh copy from http://philg.uk   via the Retro/GrantSearle etc page

I've added an "X" command, after a successful assembly 'X' will output an Intel Hex format file which can be logged or copy/pasted from the Teraterm buffer.

This integrates nicely with the monitor's hex-loader so files can be saved and reloaded with ease, and its phase-aware so takes account of LOAD/ORG differences. 

The document is updated and I've included Zen images at 2800H, 3000H, 8400H and 9000H to suit 32k or 56k (64k) systems.

Given enough memory you can of course have Zen reassemble itself at other locations but memory usage takes a bit of forethought, 

usually needing blocks of memory shuffling about  :-)

I think this is probably a wrap, I wanted Intel Hex output so Zen now does everything I need, so many other projects to pursue...  :-)

When I get a mo I will list/summarize the (many) changes made in porting from Neal's Nascom version.

Cheers & thanks again for the supportive PM's  :-)

Phil

[Bill Shen]

Link to Phil's updated Zen files:
http://www.mccrash-racing.co.uk/philg/retro/Zen_GSearle-Z80_RC2014.zip

[Phil G]

Just to explain in case anyone is wary of a strange url,  mccrash-racing is my domain (we used to do GP70 motorcycle racing) and philg.uk is a redirect.

[Phil G]

I did a silly little demo video, the demo file is now included in the zip with utils (with src) to save hex files, and I corrected some typos in the doc (thanks Eric!)

https://youtu.be/DvflLeOuHK0

Everything related is on http://philg.uk  (if you use Bill's link you'll miss the other stuff...)

To load source I find a character delay of 4ms and a line delay of 300ms avoids dropped characters on long source files, to save source use "W" and copy & paste from the Teraterm buffer.

Hexloading (monitor "I" command) can be done without character delays and say a 10ms line delay.

To save object code as Intel Hex use "X" after a successful assembly and again copy & paste the screen buffer into notepad to save as *.hex

Cheers

Phil

[Bill Shen]

Thanks for the updates and video.  I'm currently tinkering with SC114 which has no mass storage.  SCMonitor uses the same RST08 and RST10 mechanism for serial input and output so it works nicely with Zen without modification.  My question is whether Zen needs to be RAM-resident?  SC114 has lots of blank space on its EPROM, so it would be nice to run Zen from EPROM.  Thanks,
  Bill

[Phil G]

>> whether Zen needs to be RAM-resident?

It does Bill, it writes within itself, wouldnt be a huge task to separate it out but its almost 40 years since I first used it and as far as I know Zen was always ram based - Sharp MZ80K, Nascom, TRS80, Eaca Genie & of course the CP/M version , all used ram-based Zen :-)

One thing I forgot to mention before is that once I had a version running, all subsequent development of Zen was done with Zen on the Z80, which was a fun timewarp experience!

I have some of my old Zen source from the Genie days, some on cassette, some on paper, mostly ham radio stuff.  I did fancy transceivers for RTTY and Morse, with buffers, memories auto answer, messaging etc, I still have the morse source but cannot find the RTTY one anywhere.  I do have the Zen source for the ROM-only Z80 CW reader but not for the RTTY extensions though it would be easy to recreate as I still have the eproms.  So much stuff on cassette was lost over the decades.

An unfinished project was a standalone Genie tape reader circuit, I should revisit that before the tapes become unreadable :-)

Cheers

Phil

[Bill Shen]

Phil,

Thanks for confirming Zen needs to run in RAM.  SC114’s EPROM can be switched out and replaced with RAM, so I think I can figure out a way to copy its 32K EPROM to RAM and then run SCMonitor in RAM which, in turn, invoke Zen that was originally stored in EPROM.  It is a bit elaborated but should be do-able.

  Bill

[Phillip Stevens]

On Saturday, 11 March 2023, Phil G wrote:

I've updated Zen, if anyone's still interested please download a fresh copy from http://philg.uk   via the Retro/GrantSearle etc page

I've added an "X" command, after a successful assembly 'X' will output an Intel Hex format file which can be logged or copy/pasted from the Teraterm buffer.

Phil thanks for adding that very useful feature to Zen. With the ability to "save" assembled programs in a useable format like Intel HEX (rather than cassette tape format) the workflow is now complete.

Like Bill, I've made some small adjustments to your code to make it fit in with my workflow. For reference they're summarised below.

 - converted the source to cross-assemble with z88dk-z80asm (change the OR character from . to |, and change the single character quoting from "n" to 'n'),

 - which allowed me to put Neal's reference comments back into the source there's no longer a space constraint (cross-assembly).

 - made it an independent "application" by saving the stack (in an original author provided location STACK) and restoring it on exit, and using a RET rather than a JP to return from the program.

 - some minor tweaks to the serial output to prevent multiple call bounces.

Cheers, Phillip

[Trevor C]

Hi, I have been trying out Zen and am finding that after writing a program in Zen, quitting to the monitor and then using the G <address>  to run the 

program the code then returns to the Zen Z prompt rather than staying in the monitor. Is that how it is supposed to work ?  I have never used Zen before. Most of my Z80 coding was done on an Amstrad CPC6128 with the Maxam assembler.

Using a DS1245Y 128k NVRAM which holds Zen and any other code in memory.

Like the Intel hex loader and the addition to Zen to produce Intel HEX.

When writing assembler I have been using the online assembler at asm80.com and copying the hex with the monitor hex loader which works for me.

         Trevor

[Phil G]

How does your program end Trevor?

To return to the monitor it should jump to 1DC0.  The only way it could get back to Zen is if the program didn't terminate properly  :-)

See the 'puzzle' source for an example.

Let me know how you get on :-)

Cheers

Phil

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/tQbiZ61OrA4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/08a07710-9a1b-449b-88cf-44ac3a13bafan%40googlegroups.com.

[Trevor C]

Hi Phil,

              thanks for the reply. That works. My program ended with a RET. I will remember to put a jump to 1DC0 when ending a program if I want to

return to the monitor.

                                       Trevor

[Phillip Stevens]

On Wednesday, 15 March 2023  Phil G wrote:

How does your program end Trevor?

To return to the monitor it should jump to 1DC0.  The only way it could get back to Zen is if the program didn't terminate properly  :-)

Phil, as a thought. Perhaps it would be more robust and portable if your monitor could push a return address onto the stack before jumping to code using the G instruction?

That would enable you to change the location of the monitor over time, and also would allow any code or application to return to the desired place without needing to know the internals of your monitor. Hiding the internals of the monitor from the application would seem to be good and normal practice.

Anyway, just a thought for you to consider.

Cheers, Phillip

[Mark T]

I haven’t tried zen or Phil’s monitor yet, zen sounds like something I wish I had back in the 80s if I had known about it, instead of hand assembling code.

I think there are advantages and disadvantages of using jump or return to return to the monitor. Jump will always work so long as you know the address, with return you don’t need to know the address but it won’t work if the target has been messing with the stack pointer. Maybe providing both options is possible. 

Using one of the reset instructions could also be usefull to insert breakpoints with a continue option in the monitor to carry on after the reset.

As I said at the beginning, I haven’t tried Phil’s monitor, so no idea if he already implemented any of the above.

[Phillip Stevens]

On Thursday, 16 March 2023, Mark T wrote:

I think there are advantages and disadvantages of using jump or return to return to the monitor. Jump will always work so long as you know the address, with return you don’t need to know the address but it won’t work if the target has been messing with the stack pointer. Maybe providing both options is possible.

Absolutely. Both (3) options are all possible simultaneously; a) having a valid return address on the stack; b) using RST 0 and / or c) jumping to a specific address.

But in fact, I'd go as far as to say that not having a valid return address prepared on the stack makes things confusing for new programmers (commonly users of the RC2014 Mini / Micro / Classic).

By that I would provide some examples where returning to the monitor with a RET is the accepted normal method to return from an assembly program within the existing RC2014 software landscape.

• Most example assembly program examples in books and references terminate with a RET instruction, or possibly if they're CP/M related they would with a JP 0000h.
  
• Both the SCM Monitor and RomWBW dbgmon Monitor provide a return address on the stack before their G xxxx or R xxxx instructions respectively, and they expect their applications to terminate with a RET. See Section 2.12 of the RomWBW ROM Applications Manual for details.
  
• MS (NASCOM) Basic expects that assembly programs will terminate with a RET. See Appendix D of the Nascom BASIC Manual, for more info on calling assembly code from BASIC.

The other option is to finish with a RST 0 or JP 0000h. Both of these work without further effort already, but they don't allow the continuation of an Assembly subroutine called from a BASIC language program or the seamless continuation of a debugging session with the monitor, as this is effectively a soft RESET.

 

Using one of the reset instructions could also be useful to insert breakpoints with a continue option in the monitor to carry on after the reset.

True, but it is probably out of scope for the available capacity of the 8kB ROM. What would be easy is building a RST jump table in RAM, prior to launching the monitor or Basic, to enable the RST destinations to be remapped by the user which would then allow a debugger to be developed as an application loaded by the monitor.

Again, just my 2 cents, for thought.

Phillip

[Phil G]

Just some closing comments,  please remember this is only a half-a-K monitor and theres very little room to manoeuvre. 

 I've done a couple of small changes to the 'G' command, first it pushes the monitor return address, and so programs can return to the monitor with a RET,

and previously an unintentional G command was committed, it can now be aborted with a '.' full-stop.   I took the liberty of changing the basic version string to 4.7m for 'monitor',

if this offends just change it back, rom address 021Dh.  The files on http://philg.uk are updated though you may need to flush your cache.

Cheers

Phil

[Bill Shen]

Phil G,
I figured out how to copy entire SC114 EPROM contents to RAM and run SCMonitor in RAM.  I like to locate Zen in 0x5000 of  SC114 EPROM so Zen is also copied to RAM starting at 0x5000.  Then I can just jump to 0x5000 to execute Zen.  Could you provide a copy of Zen relocated to 0x5000 or tell me how to do that?  Thanks,
  Bill

[Phil G]

Hi Bill. When assembling Zen with Zen, the source takes up most of your memory which makes some origins easier to create than others.

5000h is an easy one.  Run Zen at 8400h, load zen.zen (E command) edit both the ORG & LOAD lines at the beginning to 5000H, assemble, 

then open a Teraterm log file, and do an "X" for the hexfile. Close the log, save it as Zen_5000-5E3D.hex  and then edit the X & the Zen prompt out of it.
I've already done this for you here: http://www.mccrash-racing.co.uk/philg/retro/Zen_5000-5E3D.hex

Cheers

Phil

[Bill Shen]

Thanks,  I tried it out and it seems to work fine.  I will now make the necessary mod to SC114 EPROM to install Zen at 0x5000 and add it to SCMonitor's API directory.
  Bill

[Phil G]

Sorry about this, I've just updated the Zen zipfile again.   I've been using Zen itself to develop Zen and in large source files was frustrated by the lack of a 'goto linenumber' command in the source editor.  Having to do 'T' for Top then 'D#' for down n lines eventually got to me. Consequently I've added a 'G' command to the editor, for example G67 will make line 67 the current line. Remember though that if you follow this with an 'E' command, that enters text before the current line, as it always did.

Apologies, I do think this is a wrap now.  The Zip on http://philg.uk includes Bill's 5000h version, and one at 1000h that someone asked for, plus all the previous load addresses.

(Obviously the one you choose has to match your hardware). It also has an updated doc file & readme with the new and the modified commands listed.

Cheers

Phil

[Bill Shen]

Anyone with SC114, some W27C512 EPROM and ability ot program W27C512 can try out attached updated EPROM hex file for SC114.  It now contains Zen program at 0x5000.  Since Zen is RAM resident, the updated EPROM as a small transfer program that copies the entire SCMonitor from EPROM to RAM and then execute Zen in RAM.  Invoke Zen by typing "Zen" at SCMonitor prompt.
  Bill

[Phillip Stevens]

On Sunday, 19 March 2023, Phil G wrote:

Sorry about this, I've just updated the Zen zipfile again.   I've been using Zen itself to develop Zen and in large source files was frustrated by the lack of a 'goto linenumber' command in the source editor.  Having to do 'T' for Top then 'D#' for down n lines eventually got to me. Consequently I've added a 'G' command to the editor, for example G67 will make line 67 the current line. Remember though that if you follow this with an 'E' command, that enters text before the current line, as it always did.

Thanks Phil.

 

Apologies, I do think this is a wrap now.  The Zip on http://philg.uk includes Bill's 5000h version, and one at 1000h that someone asked for, plus all the previous load addresses.

I've updated my copy to include your "Gnn" command, too.

Just to note my only differences to your version are:

• Preserves the caller stack and on "Q" quit it restores the stack and returns to the caller.
  This opens Zen up to be run from many more places, including the SCM, legacy RC2014 MS Basic ROMs (2022 and earlier, using hexload), and other ROMs complying the "Searle" MS Basic RST based serial API.
• Converted the source to work with z88dk-z80asm (cross compiled), and added back in Neal's comments. This makes maintenance and reading source code for interest simpler.
  Alternate versions with different origins can be prepared just by changing the ORG and following the two line instruction.
• Slightly simplified the serial interface and removed the null patch bytes, since we can add or remove stuff easily on a PC with cross compiler.

Hope that's useful too.

Cheers, P

[Phil G]

Its all good.  The reason I used Zen for dev rather than a cross (apart from to get the very first iteration loaded) was purely for nostalgia, I enjoyed the timewarp. But having lived that experience, its better maintained in a cross :-)

Strangely, I later found the manual for the Sharp version of Zen,  and it already had the goto line number command, but no source so I've no idea if they did it the same way (mine does top, down n). No idea why it was removed, its only a few bytes!

I would be nice to find the source for the Sharp one as the manual suggests it includes monitor commands like memory dump, run a M/C program, etc though I do like that the current one is still under 4k.

Cheers

Phil

[Bill Shen]

Is there a way of entering Zen without initialize the editor's memory?  It is like "warm boot" for BASIC so editor's content is not initialized.  The reason I ask if because my early Z80 SBC designs were ROM-less with battery backup for RAM, such as Z80SBC64.  I thought it may be interesting write program in Zen, exit to test it, possibly cycling power, and re-enter Zen to resume program editing.
  Bill

[Phil G]

Zen itself doesnt initialise Bill, its only in it initialised state immediately after loading. Once loaded, thereafter it always 'warm starts'. Is it because your rom image is being copied in every time (which is initialised)?   

This is how I worked on Zen, frequently switching between it and the monitor. On re-entering Zen with "G5000" the source & status will be exactly as you left it.

Cheers

Phil

[Bill Shen]

Ah, THANK YOU!  in SC114 I do copy Zen over every time it is called.  I can have a separate command not to copy EPROM to RAM, just page out EPROM and jump to Zen.  For battery-backed SBC, Zen is already reside in RAM so I don't need to reload, just jump into it.  Thanks!
  Bill

[Phil G]

No probs, its just familiarity  :-)
I also like nvram, its a huge bonus for boards with no disk storage.   

Although with Zen, the source, object code, symbol table, and any other tools all resident in memory, you do occasionally mess up & unintentionally overwrite something important :-)

Cheers

Phil