G80-S v1.0 Boards In Production

That’s right boys and girls! The first production run of G80-S v1.0 board has been ordered, confirmed, and are currently in production.

Some of you may be wondering what changes were made between the Beta run and the v1.0 boards. Well, to answer that question, not many. Firstly, and the most important aspect, the IEI line has been fitted with a resistor to VCC. This will allow SIO/DART interrupts if desired. It doesn’t affect current G80-S software. The other changes were simply cosmetic changes to the silkscreen layer. Everything should look pretty now.

Once the boards arrive I’ll get them checked for issues, but the layout hasn’t changed. So the only issues, if any, should be cosmetic at this point. (I had put quite a bit of thought into the board when designing it).

Also, I have designed and ordered a first batch of prototyping boards for anyone who wants to tinker with other hardware. This board will have breakouts for both the z80 bus as well as the PIO pins.  And will have a place for a Micro-SD card and a 1117 3.3v regulator. These changes will simplify modification for CP/M or testing with other hardware by allowing the user a way to expand the board while keeping the same footprint.  With stackable headers you could add quite a few items to the computer.  Just food for thought.

Happy Computing!

TinyBASIC: Variables, Memory, and Expansion

In my last blog post I shared that I have managed to integrate TinyBASIC into my monitor for the G80-S in a ‘mostly stable’ way. Now that has progressed from mostly stable to very stable. But further, the IN instruction has been revised to use variables. Which is quite handy, as it allows the programmer to not only write to I/O, but to also read from it, and make branches in his/her program as a result of those reads.

This is a big step, as it is the basis for other routines that can expand on the original TinyBASIC source code. Routines such as PEEK or POKE may need to use variables, and the ability to use variables to OUT to I/O is also important from a programmers viewpoint. And these routines just simply were not included in the original source, and I desire to have them available in my software. So as such, I’m further modifying TinyBASIC as I see fit.  And yes, when it is done I will release it into the wild.

Variables in TinyBASIC are straight forward once you understand them. To read from or write to a variable one simple needs to understand that they are nothing more than a predefined area of memory, and that they have a given structure.

This area of memory is defined as VARBGN in the TinyBASIC source. And in my personal example of code resides in 55 bytes of data starting from 0xFF00. Now, each variable is broken into two (2) bytes. However, they are not organized as you would assume, with the MSB being first, and the LSB being second (i.e. the way one would read the memory if layed out in from of him). No, TinyBASIC addresses variables just like the z80 addresses memory. I.e. if we refer to location FF88 in memory it will be listed as 88FF. Likewise, if we refer to a variable (for the sake of examples let say it is listed as 01h) in memory, it will be addressed like this:  01h 00h.  Strange, but ok.

Further, the first address of the variables is not ‘A’. I believe that it is ‘@‘ which I also believe is a pointer. But I have not confirmed this. One step at a time…

Now, this means that if we want to use variables it is as simple as figuring out which variable we want to use, and reading from or writing to that area of memory. Simple right!

As a result I have rewritten the IN instruction so that it now operates as a tool for loading a given variable for use by the program. It can be used in the following ways:

IN hh V
IN hh,V
IN hh=V
IN hhV

Where ‘hh’ is the port to write to in Hexadecimal, and V is the Variable ranging from ‘A’ to ‘Z’.

I’m still working on patching the OUT instruction to use variables. Sometimes the best way to solve a problem is to step back and let your eyes rest. And that is where I am at currently. I needed to step back until my eyes are fresh. But as of right now it can output a byte to a port.

The rest of the functions are still a work in progress. I have added a CLS function that can be used either direct or within code. I have also added a QUIT function which serves to exit TinyBASIC. So it is coming along.

Overall, my work on expanding TinyBASIC to be more usable, while maintaining a small foorprint, is progressing at a pleasing rate. And while this project centered around my G80-S computer, need is the mother of invention.  And as a result I will release the source once I decide that it is complete enough for release.

But for now, I leave you curious…

Integration of TinyBASIC

It’s been a productive weekend!   I’ve been able to integrate TinyBASIC into the monitor program.  Btw, if case you were wondering why the monitor states that it is G-DOS, it is motivation (and my intent) to integrate a FAT file system into the computer.  Likely using a SD card.  I’m currently working on the design.

But wait!  Integrating TinyBASIC into my monitor program is not all that I’ve done!  I’ve also been working on expanding TinyBASIC with the following items: IN, OUT, PEEK, POKE, and CALL.  That’s right, TinyBASIC will actually have some use other than just printing to the screen.  This will be a great tool for testing hardware designs.

As it is right now, I’ve added the IN and OUT routines.  OUT performs exactly how you’d expect:  ‘OUT NN NN’ where NN is a two digit hexadecimal number.  IN on the other hand I’m still working on.  The routine itself works, but I’m unsure how to finish it off.  What I mean by that is that I need a way to be able to assign a variable, and I haven’t looked deep enough into the code to be able to determine how to do so at this time.  For now, it simply writes the value to a specific address in memory: 0x8015. Which required me toying with memory locations built into the original TinyBASIC source.

Once I can figure out how to assign a variable to the command, it will become much more useful.  And that same scheme can be applied to the PEEK command as well.  POKE on the other hand should be as straight forward as OUT.  And this gives TinyBASIC a new level of functionality, and no more limitations on variables, as you’d be able to access memory directly.

And the best thing about this is that I believe that after expanding TinyBASIC I can keep the entire ROM (including filesystem routines) under 8K. Currently with the Monitor and BASIC the ROM is just under 5K (5013 bytes). I do not see why I wouldn’t be able to keep the I/O routines for an SD card and the Filesystem routines under 3k.  And I should only need a few hundred more bytes for the additional commands.  Of course one must also take into consideration the ability to save files from BASIC and load them again.  Who knows, but 8k is my goal.  We’ll see how well we can accomplish this.

Popular Request: Microphone Pop Filter

Well, after suggestions from several viewers on my YouTube channel concerning the issues with my microphone, I have decided to break down and buy an el-cheapo pop filter.  Nothing special, here is the one I decided to purchase:

Double Layer Studio Microphone Pop Filter

It’s nothing fancy, but hopefully it will work until I have a chance to do research and invest in an audio interface and better microphone.  We’ll see.  But the good news is that it should at least help!  So look forward to future “hopefully pop-free” videos.

And for the record, it has already been ordered.  Whether or not I can hold off until it arrives before shooting my next video, that is a question for another day.  Although I do have a video I am REALLY wanting to shoot before too long.  However I have to do a little more work to get ready for it.  Maybe I could stretch it out until this weekend?

TinyBASIC for the z80 – TinyBASIC 2.0g

In celebration of 41 years of Li-Chen Wang’s TinyBASIC (the original Open Source Operating System), and the fact my G80-S Computer needed a version of BASIC, I am proud to announce the z80 port of TinyBASIC.

Version 2.0g was derived from the original TinyBASIC 2.0 source.  The method of it’s conversion was thorough.  First the original source was compiled in 8080 mnemonics.  It was then disassembled, and compared to the original source.  It was then modified for the z80 Instruction Set.  And finally, streamlined in order to make it a little more portable.  The link to the download is below.


However, if you’d like the assembly file for the G80-S computer, here is the link to that source code.  Enjoy!


G80-S Runs Microsoft Basic 4.7b (sort of…)

As a followup to my post on interrupts, I decided to have a go at modifying Grant Searle’s I/O routines for his 7-chip z80 Computer. After quite a bit of work, I had the routines in his handler changed to conform with his code (at least I think), and function as intended (at least as far as I was able to test).

The next task was to try it with his modified version of the Nascom Rom.  And, after splicing the code, I compiled and tested…..and tested…..and tested…..

Well, the short of it is that it kind of works.  The video above says it all.  The serial routines seem to work fine up until BASIC starts up.  And at that point, my serial routines work fine, but there is some disconnect with Grant’s code that either doesn’t like my own code, or is simply amiss.

The video really does say it all.  If anyone has any ideas, or has ported Grants work over to using either the DART or SIO, I’d love to see your code.  Help a brother out… But seriously, watch the video.  It’s hilarious….

On the Subject or Intereupts

Although I have learned a lot by designing my own z80 computer, I have yet to learn much about interrupts. It’s just not something that I initially saw a strong need for.

However, since I have been looking at porting other people’s code over to my system I have come to realize just how important other people see interrupts to be. In fact, from what I can tell,  more often than not this is the case. At least with the code I have examined.

This means, that if I am to port some of the code I would like to use, I need to learn about interrupts.

The first thing of note is the hardware situation. On my first run of boards, what I’m calling the Beta Boards, the IEI line on the DART was left disconnected/floating. As it turns out, this is a no-no. This pin is the Interrupt Enable Input. Meaning it’s the enable on the SIO for interrupts. Without a High signal on this pin, there are no interrupts. So, I’ve fixed this issue on my new design by adding a resistor between IEI and VCC, and I’ve used a bodge resistor as a solution on my Beta Board.

The second thing to note is the different types of interrupt modes on the z80. There are three: Mode 0, Mode 1, and Mode 2. From what I can tell, Mode 1 is the most straight forward. In this Mode a low on INT will call the z80 to perform a RST 38H instruction. Which is essentially the same thing as a CALL 0038H. However, in order to return from this instruction the system requires a RETI instruction. So keep that in mind.

Mode 2 is interesting because it allows you to jump to a specific routine pointed to by a reset vector. In this Mode the upper 8-bits of the address is held in a register. And the lower 8-bits is placed onto the data bus by the peripheral. Trying to understand this Mode almost caused my head to explode. A little complex for our needs.

Mode 0, as I understand it, is a reset mode that is designed to be compatible with the 8080. Where in the peripherals place data on the data bus. I’m not going to presume to understand anything about this Mode.

So therefore we’ll be using IM 1 where polling is not usable. But wait, what if we need multiple devices? Well, luckily there is a way around this. Although I suppose it could be a little slow. When the z80 receives an interrupt the routine checks all the peripherals before deciding how to react. Good thing our system clock is at 6mhz. We may even need a little more speed. But in the end, if we have to, we can always use IM 2.

Here is an example of working code of Interrupt Mode 0.  I found interrupts a little difficult to understand at first.  But hopefully a very simple example of an interrupt routine will be enough to help the beginner.

IM 1 Example

G80-S Micro Schematic and Source

I’ve been meaning to upload the source and the schematic for the G80-S Micro for some time now.  I just haven’t gotten around to it.  However, I had some time to do so this evening.  So attached here is the schematic, and the source code.  It’s the v0.25b version of the software.  Use them well.

Also, a link to the Source has been placed on the product’s page in the store for the Beta boards.  So if you want to buy a board, you can download the software there.  If you don’t want to buy a board, but want to play with my design, the schematic is here and the source as well.  Have fun!

DIY CH340G USB to Serial Adapter

Looking for a solution to connecting my 6502 Badge to my PC, I came to a dead end when I discovered that my USB to Serial adapter had been lost, stolen, or worse, discovered by someone else.   What was I to do?!?!

Luckily enough, I had recently ordered several (read: 50) CH340G USB to TTL Serial adapters.  Knowing that these were supposed to be pretty much plug and play, I decided to break some out and play with them.

The first thing that I needed to do was find an adapter board.  The CH340G being in an SOIC-16 footprint, there was no way that I was going to attempt to “dead-bug” the chip onto a piece of perfboard.  My eyes are not what they used to be, and I didn’t feel like messing with it.  I had made some SOIC-14 adapter boards several years ago, and wondered if those would work with a little modification.

Looking at the board, it became apparent that the two bottom pins would need to be bent up to prevent them from shorting out on what would end up being the VCC line.  Looking at the pinout to the chip proved this would be no big issue, as the two pins that would be bent upwards were XO (Oscillator Out) and CTS.  The XO line would not be needed, since I planned on using a CAN Oscillator.  And the CTS line could always be tapped with a piece of wire-wrap wire to break it out to the board.  But in this case, it wasn’t currently needed.

Knowning that the pinout would work, I soldered the chip to the adapter board, and began laying out the USB-B connector, DIP-14 Full-size Can Oscillator, and the IC on a 5x7mm perfboard.

Once I had a suitable layout, I went to town, and within 10 minutes I was ready to test the connection between the IC and the Computer.  Plugging the device into the computer I hear the audible notes from the PC, letting me know that something had been found.  I pulled up the Device Manager, and I was greeted with the sight below.

Thats right, It worked!  Now I just needed to finish wiring it up.  I decided that since the 6502 Badge had a pin for Reset, I better include it into my design.  And I quickly found a push button.  After wiring everything up I knew I needed a way to test the device to ensure it was working properly.  I remembered that I had a ATMega16 on a 5x7mm perfboard.  I pulled up the Arduino IDE and wrote a short sketch to turn on and off an LED and do a write to serial at each state change.

After I was done, I plugged the CH340G board into the compture wired it up to the ATMega16 board, which instantly began to blink, and checked my Serial Port in TeraTerm.  The next thing I knew I began seeing text on the screen.  “LED On…LED Off”.  It was a success!

So now I knew that not only did my CH340G ICs worked, but I also knew what I needed to do to get them embedded in my projects.  And now that I knew a thing or two about them, I think maybe the CH341A Parallel Port variety may come in handy as well…  Seems like it could come in handy in many different projects….

Kaypro Restore Pt 1: Replaced Sockets and Video Activity Capture

The Kaypro restoration is coming along, but not a lot of headway has been made.  I’ve manage to convert the board back the way it was when it left the factor, as can be seen in the picture below.  However, there is at least one problem with this.  U87 was factory suggested modification, and I have learned both from a reader on this blog as well as a guy on Facebook that it was a service repair of some sorts.  Something about corrupted data.  So that repair will be redone.  I guess it is for the best, seeing as how the previous sockets were worn from the constant pressure of the machine pins over the course of the last 30 years.  Rather that just sacrifice the chip, the person who did the original repairs sacrificed both a chip and a socket.  And the sockets caused the factory placed sockets extra wear. In other words, it needed to be replaced.

The next step was to take a look at the CPU’s activity, and see how everything was going.  And It appears that the CPU is hopping along quite normally.  However, I did notice that the clock appears to not quite be 2.5mhz.  Rather, it appears to be a stable 2.4mhz.  The picture below shows (from top to bottom) the clock signal, the MREQ signal, and the IORQ signal.

All and all, it appears that the machine is running, executing code, and generally performing routine memory operations as well as I/O operations.

As for the video problem.  Well, the good news is that there is at least some type of video signal.  But I’m not sure if it is garbage or actually has something to it.  The pictures below shows (from top to bottom) the Vertical Sync, the Video signal, and the Horizontal Sync.

I’d love to know if anyone knows if this looks pretty standard.  Or if there appears to be something amiss with these video signals.  Because, like I have mentioned in the past, I have no knowledge of video signals or CRT displays.

However, I have see mention before of a pretty easy circuit to fabricate that combines the vertical, horizontal and video signals into a single composite video signal (this was for the Commodore PET). And I may end up sitting down at the bench one day in the next week or so and solder this up.  However, I find it hard to justify using the time for that.  Since I do have my G-80S prototype video board under construction at the moment (another project involving video signals which I have no understanding of).  However, I’ve attached the following picture of a schematic I have found for the mod.  It seems interesting enough.

I have no idea if it’ll work.  But I cannot imagine that the signals are that different.  But who knows, like I said, I know nothing about CRTs or video signals.

So, a little work has progressed, and will hopefully continue.  Also, I’m still looking for a boot disk for the working Kaypro 2X.  If anyone has the ability to make me one for a decent price I’d be a paying customer.  Shoot me a email, and we can talk.