RomWBW on S-100 Project discussion...

[Douglas Goodall <douglas...@mac.com>]

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.