Re: RomWBW on S-100 Project discussion...

[yoda <yo...@r2d2.org>]

Oh - my mistake.  My approach was to build the monitor from the opposite direction.  Instead of dropping code I start with a new file and add just enough code to get the serial port working. My basic first step is to get sending characters out in a loop which I call the scream test.  This can be done with all code in ROM and not using RAM which is the critical first step as you don't know you have working RAM yet.  Next I add the code to check the memory and find the TOP of RAM.  This allows you then to set a  stack pointer and use subroutines.  If you look on John's pages there is a RAM test program that uses no subroutines that is all in line code so it will execute from ROM using no RAM - get this running with your serial I/O routines (you will have to modify it some because he does not use the serial I/O card, but it is not hard).  Once you have that all working then you can start cutting and pasting code from John's monitor code and implement one function at a time and test it.   I know it is kind of tedious but you can rapidly build up the monitor with the functions you need.  I find some of the routines he provides not entirely useful so I did not bring those over.

Your comment about C is a little bogus.  A reasonable C compiler will emit code that is relatively the same as you writing in assembler for these basic functions in the monitor.  The beauty of doing it in C is that this code can be recompiled for another processor and not have to be re-translated to another machine assembler.  Looking at the code I think it should be possible to write the monitor with less than 100 lines of assembler code (even less for memory mapped architectures).   I am writing the 68K monitor this way as I go forward so for example, my memory display, change memory, fill memory, etc should be able to be reused in the Z80 monitor or any other machine monitor. 

On Saturday, January 26, 2013 7:08:16 PM UTC-6, douglas_goodall wrote:

Master Yoda,

The files I sent you were an attempt not to re-write the master but rather to simply drop out code

that outputted data to devices not present. It bothered me that the code as it came from John 

assumed his complete and exact configuration of boards. This meant that if one of our

configurations differed, but our hardware was at the same address used in his, that unexpected

results would occur when the wrong commands were issued.

I acknowledge that a serious re-write would be beneficial, and that using C would be desirable

keeping in mind there is only 2048 bytes of ROM space for the entire thing. When I dropped out

support for boards I don't have, the space remaining for expansion grew to over 800 bytes.

Obviously we would have to be very careful in C to get everything done and still fit in the

allowed space.

Douglas Goodall

On Jan 26, 2013, at 2:31 PM, yoda <yo...@r2d2.org> wrote:

Hi Douglas

I took a quick look at your files and this is not the direction I was thinking.  You are not partitioning the code very well for example the master-dwg.asm has all kinds of equates in it that are for i/o specific devices that are not used in that file and the same for some of the i/o files. Here is the direction I plan to go:

1)  basic init - enough to setup stack pointer and anything needed to get started

2)  everything is written in C as possible.

3)  I/O specific initialization in separate files and named to identify the type of I/O or platform or card

It would follow something like this

1) for init on z80 do a quick memory scan and find top of r/w Ram and set the stack to top of memory

2) command interpreter is written in C and second part of init

3) the initial C file can call the init routines of the the I/O modules or a lot of it can be written in C and/or inline assemble in the C file

4) A lot of the monitor can be machine independent - like display memory could be a pure C file that can be use on Z80, M68K or any processor

5) for basic I/O need low level getc(), putc() and getc_stat() to start with.  PutString() etc can be built from these and be machine independent

Config stuff can be in Makefile depending on the flexibility.  You should have one Makefile and you don't need to copy source around, use the VPATH capabilities of modern make command.  You can separate out platform specific code or platform code by using ${TARGET_MACHINE} or ${TARGET_BOARD} in the Makefile, so in the end you can do make -DTARGET_MACHINE=foo and it make will take care of compiling(assembling) the write files with the right FLAGS.

So if partitioned correctly we should be able to same make -DTARGET_MACHINE=m68k or make -DTARGET_MACHINE=z80 and we can build monitor for those 2 boards.  Adding processors and boards becomes very easy then and the original files don't really need to be touched.  You just add the new files into the Makefile and add the source files to the correct subdirectory.

Let's keep the discussion in the NVEM-S100 since the project is really about that

On Friday, January 25, 2013 11:21:33 PM UTC-6, douglas_goodall wrote:

Master Yoda,

Here is a version of MASTER that I did my art on. There are macro definitions in config_s100.asm that

are used to conditionally assemble MASTER on the basis of hardware declared to be present.

If I missed an include let me know.

This was meant to allow use of the Interfacer boards or the IO card.

I just thought you might like this as a starting point for something.

I allow myself hope you might like my makefiles.

Douglas

(ichibrosan)

--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To post to this group, send email to n8...@googlegroups.com.
To unsubscribe from this group, send email to n8vem+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/n8vem?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

---

Douglas Goodall, http://goodall.com

Note: I don't use messenger, or skype, or facebook, chat programs in general. Having always-on open communication links through massive public servers I don't have control over seems like too much of an invitation to be infected by a virus or bot. It is bad enough that my Mac wants to stay in periodic contact with Apple's cloud. Skype was tempting before Microsoft bought them. There have been too many examples of remote session links being abused by vendor employees. Even "back to  my mac" makes me nervous. There was a recent episode where Apple cooperated with a social engineer and compromised someone's entire electronic persona. If you want to speak with me, calling me on the phone works well, and you don't have to wonder if the electronic mail got through or not. When I say "Hello, this is Doug", you know who you are talking to. Just in case you were curious.