Machine code monitor for RC2014

[Steve Cousins]

Hi all

I've written a classic machine code monitor for RC2014 systems.

The monitor has the following main features:

* Boot loader to load Intel HEX files from a PC or similar

* Memory display and editing

* Register display and editing

* In-line disassembler

* In-line assembler

* Breakpoint debugging

* Single step debugging (without the need for special hardware)

* Supports both serial module types (6850 ACIA or Z80 SIO/2) by detecting which module is present

This release should be thought of as a preview, as it is an early version and needs more testing.

I've only tested it on one RC2014 system and it seems fine. Hopefully the serial module detection will prove reliable on other systems.

The current build is in the form of an 8k ROM which can be used in place of the Microsoft BASIC ROM. 

Information, including source code and ROM image, can be found at scc.me.uk

I've attached the user guide.

I'd be interested to hear what you all think.

Steve

[Jan S]

Hi Steve

Wow, Great work!
Looking forward to give it a go :-)

/Jan

[Phillip Stevens]

Hi Steve,

looks very nice!

Lots of features. Setting soft breakpoints is a real addition!

I note from your manual that you've got taking action on the HEX checksum byte as a TODO.

But, when I read your code, you're only one instruction off having it done...

You just need to check that the checksum is zero, once the line is finished.

Just replace this:

; Get checksum byte for this record

@Check:     CALL HexGetByte     ;Get checksum byte

            ADD  A,C            ;Add to checksumm

            LD   C,A

; Should test checksum... TODO or not bother calculating it!

with this:

; Get checksum byte for this record

@Check:     CALL HexGetByte     ;Get checksum byte

            ADD  A,C            ;Add to checksumm

            OR A

            JR NZ, @bad_chk     ; non zero, we have an issue

; Should test checksum... TODO or not bother calculating it!

Working load_hex code here in my drivers for the YABIOS, which has the assembly in z88dk, for comparison.

I arrange the read loop slightly differently, to allow handling different message types before data bytes are handled.

This allows me to read ESA messages, and write to any memory bank.

I've written my YABIOS monitor in C (compile with sdcc within z88dk), because its easier for me to add new features.

I'll have a look at your dissassembler, and see if I can understand it enough to borrow to my own evil purposes.

Cheers, Phillip

___________________________________________
Phillip Stevens
GSM: +61 4 3322 0688
mailto:phillip...@GMail.com

Key: E0E09601
___________________________________________

--
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/eb914663-06db-4c78-9596-f9175c5961f2%40googlegroups.com.

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

[Steve Cousins]

Hi Phillip

Wow, that was a quick and detailed look at my code and documents. I'm impressed.

You are quite right about testing the checksum being only one instruction away. The code you supplied is a good and efficient solution. 

I was aware I already had the checksum calculated and only needed to check 'C' is zero, but had not decided what to do if an error was detected. The terminal would keep sending lines of hex records so I didn't just want to simply return to the main command line loop. With everything else I wanted to do this just got left.

Your code is indeed a better and more generic with support for other record types, but I don't think it is needed for the current RC2014 implementation. I'll have to leave myself a note to 'fix' this if larger banked memory starts to become popular on the RC2014.

Yet Another BIOS. I like it. Perhaps my monitor should be Yet Another Monitor. It's ok to reinvent the wheel when it is a hobby, no so much when it is a job.

I like working in assembler. C is just cheating! Anyway, assembler is a luxury compared to working straight in hex. Did a lot of that back in the day. Still remember many of the op-codes.

I think the trick with both the assembler and disassembler is analysing the instruction set and breaking it down into efficient data tables. It seems to me the less code you have to write to handle exceptions the better. Of course if you end up with megabytes of code to decode the tables you might have the wrong solution! It is therefore a compromise.

The monitor source code includes the tables I use, but this will probably be difficult to follow on its own. I wrote a tool in VB to take the tables I use in my IDE's assembler and disassembler, and convert them into the assembler source tables you have. I've attached this program and the master data tables. I think looking at these tables will be the best starting point.

My first study of how to write an assembler and disassembler was not great. I eventually realised that the instruction set was carefully designed to be implemented in as little electronics as possible. The code to do the disassembly should therefore end up simple and elegant, to match the limited electronics those guys could put in a chip. That's when I got my head around looking at it from the hardware decoding angle. Of course, electronics works somewhat differently to software, so the software to decode instructions takes a relatively long while. All this leads me to think my solution could be greatly improved, perhaps at the cost of bigger tables. I may revisit this at some point, but would rather move on to the next target.

When I later wrote the simulator for my IDE I did effectively use larger tables for huge performance gains. But the tables would be too big of the monitor ROM. The simulator was optimised for speed, while the disassembler was optimised for size.

Once I had the tables for the disassembler, the assembler just used them in reverse. It was a nice feeling to see that bit working.

Good luck trying to figure out how my code works. I hate trying to follow other people's code. While you can always learn some new approach or pick up a trick you missed, it just doesn't appeal to me.

Steve

[A A]

In terms of a disassembler a really small one can be found here:
https://github.com/z88dk/z88dk/blob/master/libsrc/debug/disz80.asm#L48

About 1090 bytes but it won't deal with undocumented instructions, even common ones to do with splitting the index registers.  And of course, it's probably not amenable to dual duty in combination with an assembler.

A bit OT but Philip is this a bug?

_bank_get_abs:

pop hl

push hl

_bank_get_abs_fastcall:

push af


It looks like "bank_get_abs" is a standard linkage entry point (parameter on stack)?  But the return address will be what's popped if that's the case.

[phillip.stevens]

AA yes, sigh, it is a bug.

I still have trouble remembering that the RET address is always there.

Can't relay adequately how much time I've spent learning C always pushes a return, and me forgetting that fact. You found yet another case of this.

[Spencer Owen]

Hi Steve,

I got a couple of hours at the weekend to test this, and it works great!  It was intuitive enough that I was able to test out almost all of the features without even referring to the user guide :-)

If anybody else is looking to dive in to the bits and bytes of the Z80 then this is an excellent way to go!

Thanks

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/4eaa6218-2cb9-4e65-b7a9-52ba57ff4678%40googlegroups.com.

[Steve Cousins]

Thanks Spencer

Nice to have confirmation that it works on another system and that it made sense to someone other than me!

It seems to me that most people here are quite experienced and can therefore go off and do their own projects, and use software like my monitor with only a little dipping in to the user guide.

However, I think there is a much bigger potential audience for the RC2014 who do not have this experience. For such people the learning curve to progress from the BASIC ROM is probably quite steep. 

I have therefore started to write a tutorial for the monitor. This starts right back a the very very basics, and should help those with little or no experience of machine code.

Steve

[Peter Fielden-Weston]

At last! A monitor program for the RC2014 that properly formats the output of its memory listings.

I really did wonder how Dr. Scott got away with his unaligned tables.

Peter

[Steve Cousins]

In order to help make the Small Computer Monitor more accessible to those with little or no experience of machine code programming, I’ve started to write a Tutorial.

I’ve complete about the first 3rd of the Tutorial, which introduces the concepts and takes the user through every detail of entering and running a very simple program using the monitor.

I now need to extend this to introduce all the monitor’s features along with some essential programming skills.

I would appreciate any feedback. Is the idea of a detailed tutorial even relevant to those interested in retro computing today?

Remember, the Small Computer Monitor User Guide is the reference document for those with experience of machine code and machine code monitor programs.

I've not been on the RC2014 scene long, so I may not have picked up a good feel as to where everyone is. I can see that there are lots of experienced people here who are happy to write their own stuff and modify other people's projects, but I suspect there are many more who have not had this experience and would be finding the next step from the BASIC ROM to be a steep learning curve. If so then this tutorial might help. If the only people interested in retro computers, like the RC2014, have already passed this stage, then the tutorial is of little value.

Steve

[Jan S]

Hi Steve

I've been idle far too long concerning my "little electronic projects", and I'm really looking forward to give your monitor a go :-)
... and thanks for sharing your work with us here :-)

Best regards
Jan

[David Hester]

Steve

I had burnt an eprom with the hex file and I get the * command prompt but when i type anything I get bad command. I have tried this on a RC2014 mini, an RC2014 on and 8 slot backplane with SIO and a Veroboard RC2014 with the 6850. All give the same result.

Any ideas before I waste another chip?

On Sunday, 19 November 2017 00:31:26 UTC, Steve Cousins wrote:

[Steve Cousins]

Hi David

I've only had a few people feed back reports so far, but essentially the HEX file I posted does work.

It works here with both the official SIO/2 card channel A and the official 68B50 card.

If both the SIO and the 6850 set ups give a prompt, and I assume the signon message "Small Computer Monitor...", then the code is basically running pretty well and has correctly recognised the serial device you have. To get that far and then fail seems odd.

I assume it is the official SIO/2 card, as it turns out Grants Searle's original SIO implementation and Dr. Baker's version after that use a different addressing scheme whereby the registers of the SIO are mapped to the same 0x80 to 0x83 range but in a different order. So Dr. Baker's card should not get as far as the prompt. I only discovered that when someone else tried the posted version and could only get it to work with the 68B50. I hope to be able to add support for this variant soon, but for now its a no go.

It must be a clue that both setups do the same.

I assume you have verified the EPROM again in case of a corruption. This seems a possible explanation.

This might seem a silly suggestion, but you are putting a space between the command letter and the parameter. The easiest test is just type a question mark character followed by return, as there are no parameters to trip you up.

When you type a command does it echo back to your terminal? or does it simply not show or are corrupt characters shown?

Can't think of anything else at this time. I hope something here gives you a clue to resolve the problem.

Steve

[David Hester]

Steve

I reflashed with a new downloaded HEX file and used a different ftdi cable and IT WORKS.

Can't wait for the next part of the manul.

Thanks

[Steve Cousins]

Good news, thanks for letting me know.

Steve

[Dave Pucknell]

Hi,

Does anyone have this already converted to a ROM file? If not Ill make one.

DAVE

--
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/8401cada-0421-4472-911f-e15a2e1025c3%40googlegroups.com.

[Steve Cousins]

Hi Dave

Does your programmer not support reading an Intel Hex file?

I have not had to create anything thing else during development. What exactly is a ROM file? Just a binary image without any error checking?

If there is some other format that would be useful to others I'll look at producing the relevant file for the next release.

Steve

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

[Dave Pucknell]

Correct. Just a binary file starting at 0000h ...

I use the SD Memory Dump module instead of a ROM with 64k RAM.

So that removes the need for me to flash any ROMS. I know it is a non standard setup but works for me so far!

DAVE

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/76707d26-3753-4db0-9658-cd811c8018c7%40googlegroups.com.

[Dave Pucknell]

Correct. Just a binary file starting at 0000h ...

I use the SD Memory Dump module instead of a ROM with 64k RAM.

So that removes the need for me to flash any ROMS. I know it is a non standard setup but works for me so far!

DAVE

On 30/11/17 23:20, Steve Cousins wrote:

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/76707d26-3753-4db0-9658-cd811c8018c7%40googlegroups.com.

[Steve Cousins]

Hi Dave

I've attached a binary image of the monitor ROM.

It loads into my programmer and verifies against a chip previously programmed with the Hex file, so it should be good.

My programmer says the code is from 0000 to 1678 and has a checksum of 0012 C347, all when set for an AT28C64B EEPROM.

I produced this file by adding a little export function to the end of my assembly process, so I can use it again easily for future builds.  If you could confirm it does what you want I'll make this part of future distributions.

Steve

[Dave Pucknell]

I have just done a quick test and that works great in Rocket2014.

Now to transfer over to the real one later..

DAVE

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/ddea44f4-d136-49d2-ba2e-2c0cb180a753%40googlegroups.com.

[Steve Cousins]

Thanks Dave, good to know.

Rocket2014 looks interesting.

Steve

[djrm]

Greetings Steve,

I have your monitor working as an eprom image on my RC2014, I would like to be able to load it from within cp/m into ram.

Is there a way to do this with the pre-compiled version? I think it may need to be re-compiled to do this.

I cannot find the Small Computer Workshop IDE anywhere to recompile.

Is this something you have wrote yourself?

I have another cp/m computer, this one has a keyboard and screen. I would like to be able to use it with your monitor also.

I was thinking an alternative set of input and output functions would need to be available but the cm/m bios has i/o functions available too so perhaps a third option instead of direct hardware i/o to serial chips could be built in to access the existing cp/m i/o functions.

Kind regards, David.

On Sunday, 19 November 2017 00:31:26 UTC, Steve Cousins wrote:

[Dave Pucknell]

I prefer rocket and has some nice options. I have it in my development environment (with permission) available to download in a docker container.

rattydave/docker-ubuntu-xrdp-mate-custom:tools

https://hub.docker.com/r/rattydave/docker-ubuntu-xrdp-mate-custom/

DAVE

--
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/e8fb7049-fdd8-4cd6-bf80-5822a79081b2%40googlegroups.com.

[Steve Cousins]

Hi David

I can easily assemble the Monitor code to a different address, but at the moment it walks all over the bottom approx 0x6F bytes of RAM so will not co-exist with CP/M. At reset it simply copies a block of memory over 0x0000 to about 0x006F.

Given this issue, if you still want a version at a particular memory location please let me know your preference for the base address of the <6K bytes of code and also a base address for the 0.5K bytes of RAM it uses. I will happily post a version to match.

I had planned to tidy up the way it uses lower RAM so it fits within the constraints of CP/M rather than just overwriting a whole block of RAM - which happens to include CP/M's critical locations. Just laziness that this version does not do that properly. I should have just written to the specific locations I needed. 

Yes the IDE I use is my own and sadly is not fit for public release or I'd happily supply it.

I like the suggestion to make a version which uses CP/M console I/O. This should be quite easy to do, I think. I'd have to look into how to handle the stack under CP/M. Unfortunately I have not got as far as setting up CP/M on my RC2014 and my memories of CP/M are rather old, so there may be more to it than I'm thinking. I will look at doing this at some point but not immediately.

So the big question is: do you want the monitor to coexist with CP/M or just load from CP/M? The latter should work with the current source code assembled to a suitable location, as it can safely overwrite CP/M.

Steve

[djrm]

Hi Steve,

I think a good starting point would be to have a version with some spare unused jump vectors for i/o built at org 0x100 then I could start writing some access functions to patch in myself or use as-is with the default UART. if you get what I mean ...

Kind regards, David. 

[Steve Cousins]

Hi David (djrm)

Attached is the hex file and list file for a version of the monitor assembled to 0x0100. 

Reset entry is 0x0100

Code is from 0x0100 to 0x16EF

RAM used is from 0x1E00 to 0x1FFF

I've only tested this on my simulator.

The monitor already directs its I/O functions via a jump table in RAM. It also provides an API function to "claim jump table entry". So you just need to call this API with a new I/O function address to install it. Of course that only works once the monitor is already running. Details can be found in the user guide.

If you want to patch the code before running it then it is currently a bit messy. Below are the calls and jumps that need modifying. These all currently call or jump to the RAM jump table. Trapping these calls before they go to the RAM jump table will bypass all the monitor's internal I/O set up, which ultimately just puts jump instructions in RAM at 0x1FXX (or 0xFFXX for the ROM based version). The specs for these functions can be found in the Hardware folder of the source, in files Serial6850.asm or SerialSIO2.asm.

026E: CD 09 1F      CALL JpConIn        ;Wait for input character

0288: CD 09 1F      CALL JpConIn        ;Wait for input character

029C: C3 09 1F      JP   JpConIn        ;Wait for new input character

02A4: C3 0F 1F      JP   JpConSta       ;Check input status

0322: CD 0C 1F      CALL JpConOut       ;Output character to console

0327: CD 0C 1F      CALL JpConOut       ;Output character to console

I think all this will work in theory but have not tried it.

Good luck.

Steve

[djrm]

Thanks Steve, I'll try the new file when I'm back at the machine.

Kind regards, David.

[djrm]

Thanks Dave, I've just blundered through my first docker install and too have got Steve's monitor running in Rocket2014. probably need to read up about this now before going further, David.

[djrm]

The new file at origin 0x100 will load into a cp/m com file and run ok.
Of coarse I cannot return to cp/m afterwards without a full reset as the memory from 0 to 100 is trashed by the monitor. I guess if the monitor data area was moved then a jump to address 0 would re-star cp/m.
I'm new to cp/m and have a lot to learn. David.

[Dave Pucknell]

If you need any help with Docker just give me a shout in private email.

That goes for everyone else too!

DAVE

--
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/396bfdd3-50b9-4c55-ab07-4088bdeacbdd%40googlegroups.com.

[Steve Cousins]

I've completed a major update to the tutorial document for the Small Computer Monitor. See attached PDF.

The tutorial is aimed at those with little or no experience of machine code programming or monitor programs.

The user guide is available for those who only require a reference document.

Further info at www.scc.me.uk

Steve

[David Hester]

Steve

You have wetted my apertie for using assmbler on the RC2014. I have digital io module so was intereted in the flashing light example, is there an assember I could use to get this on the RC2014? 

[Steve Cousins]

Hi David

It is interesting that you asked about an assembler. The obvious next section for the tutorial is the move from using the monitor to enter small programs to using a full blown assembler. So I've been wondering what to do about that myself.

For now my advice is just to use the monitor's built in facilities to enter assembler instructions.

For development I use my own homebrew assembler, but it is not fit to be released. So I need to use another assembler for my examples in the documentation. But which one?

Also a few here have asked about assembling the monitor program and modifying it. Again a related problem. The monitor source is pretty tied to my own assembler. I am willing to write an export function, or  whatever, to make it usable with another assembler. But which one?

So I can't really make a suggestion yet. In fact if you figure it out please let me know. 

I'm looking for a simple assembler which will run easily on 64-bit Windows 10, but preferably be cross platform. Ideally it should be easy to obtain, install and use. It does not need all the bells and whistles. I particularly want one that is easy for my tutorial's target audience of those with little or no experience of machine code. 

Must start looking.

Steve

[David Hester]

Steve

The example you had for flashing a light, how do I deal with the Loop: part or is this beyond the monitor and needs a "proper" assembler?

Your tutorial is great and the monotor is also good. I have decided to convert my RC2014 mini into a monitor machine.

Thanks for the work you have done.

[Steve Cousins]

Hi David

You are right the monitor's assemble command does not handle labels.

This is not a disaster for small programs.

As you assemble a program with the A command, the monitor shows the machine code generated by each instruction and its address in memory.

Therefore, in the LED example, when you enter the instruction "LD A,1" which my listing shows as "Loop:   LD A,1", the monitor displays, say, "8000: 3E 01        >.    LD A,$01". It is the address 8000 which you need to know for later in the program.

In the case of the LED example the label "Loop" is at the first instruction, so if you start the program at 8000 the value of Loop is 8000. When you go to enter the command "JP Loop" enter "JP 8000".

If the ump destination is forward, not backwards, you will not know the required address when you go to enter the jump instruction, so enter a dummy address, like "JP 0", and carry on. Once the program is complete you will be able to see any address(es) you need, so go back and edit the program, this time entering the required address(es). 

It is quite quick to edit the program as you can either just use the assemble command and specify the address of the instruction you want to edit, or you can start at the beginning of the program and just press Return to skip each instruction until you get where you need to make the edit.

For very small programs this is a reasonable solution. For larger ones you need the patience of a saint or a proper assembler.

It is not impossible to write large programs without any form of assembler. Back in the day assemblers were not readily available. I can still hand assemble quite a few Z80 instructions without even looking at a reference sheet. Amazing what the mind remembers and what useful stuff it throws out!

Did my tutorial take too big a step when moving to examples that don't show addresses?

Steve

[Steve Cousins]

Hi again David

I've just drafted an extension to the LED example in the tutorial. I think you might find it interesting.

Steve

[djrm]

Hi Steve,

There is a typo in the code comment below taken from the tutorial fragment you posted yesterday.

LD A,1 ;LED bit zero ON value
CALL Led ;Write to LEDs and delay
LD A,0 ;LED bit zero ON value

The second should presumably be OFF

hth David.

[Steve Cousins]

Hi David

Well spotted.  

Any such feedback will lead to a better document for the benefit of others, so thanks for taking the trouble to report it.

Steve

[Michael Furtak]

Hi Steve,

I'm new to the RC2014, this group, and hobby electronics in general.

After getting the RC2014 together one weekend and messing around in BASIC, getting your monitor running was the next thing I decided to try. I'm happy to report that I was successful, and let me further say that your documentation is great!

This seems like a great community, and I'm eager to keep experimenting and learning.

Best,

-Mike

[Steve Cousins]

Hi Mike

Welcome to the group. Yes, it is a good place to hang out.

Thanks for letting me know the monitor program is working on your set up. Always nice to get confirmation that these projects are working in the wild.

Very kind of you to say the documentation is good. All too easy skimp on documentation and move on to something more exciting.

Keep watching this space as I'm continuing to develop the monitor. Suggestions and comments always welcome.

Regards,

Steve

[Steve Cousins]

Version 0.3.0 of my monitor program is now available.

I've updated the program, user guide and tutorial.

See www.scc.me.uk for details and files.

Steve

[David Hester]

Steve

Great work as usual.

Any plans for version 0.4?

[Colin Little]

Nice one Steve, some good enhancements and I look forward to your ongoing developments on this project.

Colin

On Tuesday, 12 December 2017 19:40:55 UTC, Steve Cousins wrote:

[djrm]

Hi Steve,

I can confirm the SIO2 second port selection is working fine at 9600 bps as well as the default first (boot) port.

I can  switch between then using console 2 and console 1 comands and reset back to console 1.

Today I tried the software running from a 2864 EEPROM chip I just acquired, programmed with an old Dataman S3.

These EEPROM devices do not need erasing before programming, saves a bit of trouble for frequently updated projects.

Nice work, David. 

[Steve Cousins]

Thanks for the encouragement guys.

So David (H) "Any plans for v0.4?". 

Well I haven't written myself a list for the next release although I've got plenty of odd notes for the future. I've included in this release some untested code to detect Grant's original addressing of the SIO. I'm waiting for one of Dr. Baker's SIO boards from OSH Park so I can test this feature and check future releases don't break it! So if this does not work a fix will be high on the list for v0.4

 

Longer term I'm starting to think about adding support for more devices like those cheap alpha-numeric LCD modules. I've just received a 2x16 character module and a 4x20 character module. Also thinking about interrupts. Another area is some form of simple filing system, but have not decided on the hardware for that. I intend sticking with a simple ROM based RC2014 system for now. Anyone wanting to go further is probably looking at CP/M anyway. 

I'm open to suggests for future features.

Colin, thanks for the kind words.

David (djrm). Wow, that was quick. By my reckoning that was less than an hour from my post here to you downloading it, spotting the new features and running a test relating to one of those features. Nice to know the second serial port feature is working in the wild, thanks. I too like the 2864 EEPROM. Will be a sad day when the monitor code outgrows that chip.

Steve

[Spencer Owen]

Awesome work Steve! Can't wait to try this later :)

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/3d9183ff-30e9-4317-9555-2479c28cda11%40googlegroups.com.

[Shaun ONeil]

Another thumbs-up here.  I noticed the addition of the self-test, which is an unexpectedly neat feature. The perhaps unintended side-effect that the I/O board's LEDs now default to off is an appreciated change.

But it's still your dedication to documentation which is truly the stand-out feature.

(no exotic configuration to test here, 28c64 in an otherwise classic/acia 32k rc2014)

On Tuesday, 12 December 2017 19:40:55 UTC, Steve Cousins wrote:

[David Hester]

Steve

Just wanted to say thanks for the tutorial on using asm80.com with your monitor.

On Tuesday, 12 December 2017 19:40:55 UTC, Steve Cousins wrote:

[Steve Cousins]

Happy new year to you all.

So a new year obviously needs a new version of the Monitor ROM. 

Version 0.4.0 is now available at www.scc.me.uk

Program, user guide and tutorial all updated.

Comments and suggestions welcome.

Best new feature IMHO is the implementation of crude timer events (without a hardware timer). Three software generated timers are provided. Accuracy depends on what else the processor is doing, but generally it is good enough for flashing LEDs and other non-critical background events. 

The RC2014 could really use a hardware timer as standard. What's on your wish list?

Steve

[David Hester]

Steve

Great work again, great new year hangover cure

Happy New year

[Tom Szolyga]

Hi Steve,

Instead of just a timer board, how about a dual serial and timer board?  This would be a CTC chip and a SIO chip on the same board.  The CTC chip would be a timer as well as a programmable baud rate generator for the SIO.  Thoughts?

Best regards,

Tom

[Steve Cousins]

Hi Tom

Funny you should mention that. It was exactly what I was thinking. Great addition to the RC2014 and it would keep the board count down too.

Such a board should include proper mode 2 interrupt IEI and IEO pins for daisy-chaining. And one input of the CTC should provide legacy interrupt support.

Steve

[Tom Szolyga]

Something like this (attached)?  What do you mean by one CTC input should provide legacy interrupt support?

Thoughts?

Tom

[Steve Cousins]

Hi Tom,

Yes, similar to your circuit.

I have a half drawn design which differs from yours in a number of ways.

My address decoding only uses a 74HCT138 with 

G1=A7, /G2A=A6, /G2B=A5, S2=A4, S1=A3, S0=A2

Y0=SIO select (0x80-0x83)

Y1=CTC select (0x84-0x87)

My design has IEI from one chip and IEO from the other come out to a 3 pin header

1=5v, 2=IEI, 3=IEO

This allows daisy chaining between modules. If each interrupt mode 2 module has this header, a link wire from IEO on one module to IEI of the next forms the daisy chain. At one end the IEI pin is jumpered to the 5v pin and at the other end the IEO is left unconnected. I propose placing this header in a standard position on the back edge (curved edge of the PCB) down near the RC2014 bus pins. Looking at the official SIO/2 card that is between port B pins and the RC2014 bus pins.

There is one thing troubling me about the addressing however. I note you have adopted Grant's very simple and sensible original register selection scheme (B/A=A0, C/D=A1). But now we have the official RC2014 SIO module's scheme (B/A=A1, C/D=/A0). Your design will therefore not be binary software compatible with Spencer's ROMs and CP/M. I am having trouble deciding which camp to join. I could design a board with jumpers to select which scheme, but I'd rather avoid that. You can have too many options!

As for the legacy (simple mode 1 style) interrupt support I have not got this all worked out, but I'm looking for a way of running an expandable mode 2 interrupt system (thus the IEI and IEO daisy chaining header) whilst still allowing legacy mode 1 devices.

To do this I need a device that can detect a simple legacy INT signal and generate Z80 mode 2 interrupts. I think the CTC can do this if a channel's input is set as a counter input with the down counter preloaded with 1. It would only detect the falling edges as the interrupt occurs so it might only be reliable servicing a single device. Ideally a level, not edge trigger, would be used. 

It might be better to use a Z80 PIO for legacy interrupt support as I think a simple level detection can trigger an interrupt. But that would not be as convenient as using one input of a CTC which is already wanted for time period interrupt and baud rate generation.

My thinking is to have a header pin on whatever module supplies the legacy interrupt support which can be linked to the INT signal of the last couple of slots of my backplane. These slots have an easy way to isolate one or more signals, so I'd isolate INT for these slots and rename it INT1 (interrupt mode 1). Devices with simple mode 1 style interrupts would be installed in these slots.

I'd be interested to hear from anyone who has a better solution or who can see a problem with the above. It would be nice if there was one common solution in the RC2014 universe for the mode 2 interrupt problem.

Steve

[Eric Matecki]

Hi,

sorry no solutions, it's some time now I didn't do any hardware dev on my '14.

But I suggest the 'back' edge of the boards should only get used for connectors/headers that connect to the outside world.

So the mode2 interrupt headers should (my opinion) go to the lower part of the front edge of the boards, these aren't yet used AFAIK.
This will make it much easier to put the '14 in a case.

[Steve Cousins]

Hi Eric, thanks for your views.

I was not considering a case. I assume you would also want to avoid connectors on the top of the boards.

Of course it rather depends on the case design as to which end of the boards will be more accessible etc.

Steve

[Eric Matecki]

Hi,

Sure it will depend on the case design.

I don't know exactly how mine will be, but it will be either rack-mount style, or Apple ][ style.

(This is OT, but getting a reasonably sized keyboard into a shrunk Apple ][ case will not be easy... but I still hope to find a way)

In both cases the outside world is connected to/thru the back side of the case.

The design of the BackplanePro makes this the easiest way to get a '14 in a case

without a lot of wiring from the boards to some sort of 'patch-bay'.

Most connectors fit on the 'back' side of the boards: serial, VGA, even a DB25 will fit (tightly !).

Most of them won't fit on the 'front' of the boards.

Personally, I don't mind connectors on the top, but other people might...

(In & Out boards have so many headers on the top, they won't fit on the back anyway, this is THE exception...)

(IDE boards too, but then the disk drive will also be *in* the case, so this is 'normal').

That small space on the 'front' has not been used up to now, probably because it's so small,

but it will fit a 3 pin header just fine.

It may not even overhang the BackplanePro, which has more space on the front than on the back.

Just be sure to put it high enough so it goes over the switches, power connector, etc...

Some people here think of the 'front' of their '14 being parallel to the boards.

So, because everybody uses their '14 in their own ways,

ultimately you'll have to take the decision were to put these mode2 headers...

My 2 cents on how *I* would like *my* '14 be in the (short) future.

[Spencer Owen]

On 2 January 2018 at 23:07, Eric Matecki <mateck...@gmail.com> wrote:

Some people here think of the 'front' of their '14 being parallel to the boards.

So, because everybody uses their '14 in their own ways,

ultimately you'll have to take the decision were to put these mode2 headers...

I have to admit that I've varied my thoughts on this over the years.  Initially, I considered the back of the RC2014 was the side that had the power connector going in (i.e. all the modules have Pin 1 at the back).  However, in recent times I've started to use it more the other way around so that I have easier access to the power switch and reset button.  But, then I often want to see the front of the Digital I/O Module, so I have slot 1 towards me and slot 12 furthest away.  A 45' angle often works as a good compromise.  

So, not only do other people use their RC2014 in different ways, each person use them in different ways too.

I agree that the connectors should ideally come out the back, although the Pi Zero Module kind of messes this up.  There isn't really a practical way to change this though, which is a shame.

Spencer

[Colin Little]

At last had a bit of time to play with the new version!!!  Another great release Steve. I like the 'Future plans' and have one suggestion - change the 'possible future additions' to 'definite future additions!  :-)
Colin

[Peter Willard]

Its really very usable... and useful

Thanks.

I love the documentation... 

Pete

[djrm]

Greetings Steve,

I think I have found a small typo in your monitor user guide, on page 4.

The ROM version of the Small Computer Monitor fits in an 8k byte ROM which is mapped into memory from address $0000 to $1FFFF. It requires RAM from $FD00 to $FFFF. The ROM is not paged out of memory during operation

I presume you meant to type $1FFF

Kind regards, David.

On Monday, 1 January 2018 12:21:23 UTC, Steve Cousins wrote:

[Steve Cousins]

Ooops. Thanks David. I'll correct that.

Steve

[J.B. Langston]

I'm happy to report that I have your monitor running with my AVR IO device after emulating the SIO2 ports on 0x80-82.

[Steve Cousins]

Hi JB

Very interesting project you are working on. Great that it works with my Monitor.

Does your IO device keep up with a Hex file download to my Monitor, with the terminal software set for no delays?

Steve

[J.B. Langston]

It worked for the simple hello world program I pasted:

:1001000031FFFF211E01CD0A01C97EA7C8CD130111

:100110002318F7F5DB10CB4F28FAF1D311C9686526

:0D0120006C6C6F2C20776F726C640D0A0000

:00000001FF

I'm not sure how well it works for larger programs. To test this, I tried to paste MicroChess and got some errors.  I'm not sure if this was a problem with pasting the hex or because MicroChess overwrote part of the monitor. The file I tried is located at http://www.autometer.de/unix4fun/z80pack/ftp/altair/microchess.hex, but I only pasted the standard intel hex format lines beginning with : and removed all the others.  This works if I load it from the SD card using my own hexloader.

I have had problems pasting into some other programs such as MBASIC due to the UART receive buffer getting overrun.  It is on my to-do list to implement an interrupt driven UART getchar routine that utilizes a ring buffer.  Right now it is using a polling routine: https://github.com/jblang/z80ctrl/blob/master/uart.c#L90

[Steve Cousins]

The MicroChess code does indeed overwrite the monitor as it begins at address 0x0000. 

In theory, with the Monitor's hex file loader, if a short program loads ok, so should a large one. 

[Jon Langseth]

On Sunday, November 19, 2017 at 1:31:26 AM UTC+1, Steve Cousins wrote:

Hi all

I've written a classic machine code monitor for RC2014 systems.

[snip]

I've only tested it on one RC2014 system and it seems fine. Hopefully the serial module detection will prove reliable on other systems.

[snip]

I'd be interested to hear what you all think.

I've been playing around with the monitor (0.4.0) on my very classic RC2014, and I really like what you've got here!

I like it so much, that I really want to use it on my own Z80 design, but to do that I'd need to make some changes. My devices are on different I/O addresses,  and I'm also thinking about relocating the monitor in ROM-space, so I can use a "loader-monitor" to select between BASIC, CP/M and SCMonitor. To do that I'd need to assemble the code, of course. But...

It may be that I'm too much of a newbie, or I'm blind.. I've been unable to compile the code using the assemblers I have at hand (sdasz80, tasm, crasm), and your source refers to SCAssembler. Where can I get a hold of SCAssembler? Or.. what tools did others use to compile?

(I saw a reference to Docker in the thread. I do not want a container for this, and I despise Docker)

-- 

Regards, Jon Langseth

[Steve Cousins]

Hi Jon

I'm glad you like the monitor program.

Several people have expressed an interest in making modifications to the monitor so I have been giving the issue a bit of thought.

Currently the source code only compiles with my own assembler which is integrated into my own development environment. It is a Windows only system.

I'm considering a number of options:

1/ Add an export function to convert the source code to be compatible with one or more readily available assemblers

2/ Change my assembler to be compatible with a readily available assembler

3/ Package up my own assembler so supply with the monitor source code

I'm not sure yet which way to go but I think I will provide some kind of solution fairly soon.

When I have a solution I'll post it here.

Steve

[Jon Langseth]

That explains why I couldn't find it anywhere!

I've been reading your code, and the way you have clean Z80 mnemonics and labeling, support for .PROC processor selecion and .ORG that even supports parsed labels is really nice. With the very useful #DEFCINE/#IFDEF macros and #INCLUDE macros, your SCAssembler really looks like a nice beast.

So, if I may vote for any of the three options, I'd vote for #3, or even #4: Release SCAssember as a standalone?

Regards!

[Steve Cousins]

Hi all

I have a new release of my Monitor (version 0.5.0) at www.scc.me.uk

Main changes:

Added support for a 68B50 ACIA at I/O address $40

Fixed assembler handling of JP (HL), JP (IX) and JP (IY)

Trapped assembler relative jumps which are too big

Added default console device selection byte in ROM at $0040

Reduced need for hex prefixes in assembler

So, not the most major update, but fixes a few quirks and adds a feature that has been requested.

This release includes updated documentation, the usual ROM image and also a version compiled to run in RAM at 0xE000. 

I have not fully tested the RAM version, but it appears to download and run ok. However, it requires RAM at 0x0000 to 0x005F for the breakpoint and API features to work properly, which I have not tested. I guess I should set up paging on my system and test it!

While I'm not expecting to ever really finish this project (there's always more you can do with software) I feel it is now quite stable and will probably not change drastically. I'd be interested to hear any comments, constructive criticism, wish lists, or whatever, so I can move towards a v1.0 release.

In the future I may attempt a significantly enhanced version, but this will probably exceed the 8K ROM limit many are currently stuck with. For now I will use the available space to polish the product, perhaps add some hardware drivers and maybe tweak based on feedback.

It has been an interesting journey so far.

Steve

[David Hester]

Steve

Have you had any more thoughts on this, I would like to give my vote for number 3.

[Steve Cousins]

Hi David

Thanks for the vote.

I've not yet decided on a solution. 

The problem for me with option 3 (package up my own assembler to supply with the monitor source code), is that the assembler is deeply integrated into my Windows GUI development environment. This environment is very quirky, has lots of odd features (bugs!) and is not documented. I find it productive as I know the thing really well, but I'm not sure if it would be a asset to anyone else. At the very least I'd have to write some detailed documentation, which would probably lead me to thinking I should tidy up the whole thing and fix the bugs and quirks. In short it would become a big job. I've looked at separating the assembler, but there is still quite a lot of work to do to make it work outside my development environment.

So I'm still considering what to do.

Steve

[Steve Cousins]

I've decided to release my development tools so that anyone can modify the Monitor.

I'll start a new thread for the development tools.

Steve

[Colin Little]

Sounds good Steve, not too onerous I hope but I am sure will be useful & appreciated tools for the group..

Tx

Colin

[Steve Cousins]

I've had an interesting session in front of the assembler.

I thought it would be nice to get the ROM BASIC working from my Monitor.

Why you may ask?

Well if you have the monitor in ROM it would be handy to run BASIC without having to change links or swap ROMs.

Also, by running BASIC with the Monitor, BASIC can inherit the Monitor's serial port drivers. The Monitor auto identifies the official 68B50 and SIO/2 modules, Dr Baker's SIO module, and also a second 68B50 at address $40. So it then only requires one BASIC image to work on all systems / configurations. Also any extra hardware drivers written for the Monitor will work with BASIC. This could be handy when developing new hardware drivers with the aid of the Monitor for debugging.

Long story short... 

I have Grant Searle's version of BASIC compiled to start at address $8000. 

I removed the "Memory size" question as just pressing return would cause it to use all memory and overwrite the Monitor's workspace. I hard coded the top of BASIC's memory to 256 bytes below the lowest location used by the Monitor. So a little space for machine code functions or whatever. Hm, perhaps I should have left the question but hard coded the default!

Grant's version of BASIC uses Restart instructions for console I/O, so I added support for these to the Monitor. So no need to mess with the BASIC code here.

So now a system with the Monitor in ROM (8K) and 32K ram from $8000 to $FFFF (ie. the lowest spec RC2014) can download the BASIC interpreter as a hex file from a terminal program. As the Monitor can handle flat out downloads (no delays) it only takes a couple of seconds to download BASIC.

To cold start BASIC you use the monitor command "G 8000" and to warm (re)start BASIC use the command "G 8003".

Another nice thing is that from BASIC you can return to the monitor with the BASIC command "MONITOR". Although this does cold start the monitor and thus puts any serial port selections back to the Monitor's defaults.

A few simple programs (flashing LEDs etc) seem to work ok, but I'm not sure if it is robust yet.

If it appears robust I'll release it with the next Monitor update.

Steve

[Jon Langseth]

Great news, Steve! Having read both source codes thoroughly, I can understand that it's been interesting, Since you have not deemed it robust yet, I'd like to give a suggestion. The "Memory top" allows to limit the RAM, so that other data can be placed above that limit, and BASIC can't mangle it. At least that's what the NASCOM manual claims it's for. My suggestion is to do as you suggest; include the command, but have a default (or even max) that avoids the Monitor RAM up top.

[Steve Cousins]

Yes, I think you are right. But it is nice to go straight to the BASIC prompt without the question. I guess you can't have everything.