Alnwlsn - Projects Repository - User contributions [en]

Geiger counter

2025-07-20T01:36:18Z

Alnwlsn:

[[File:Geiger-counter-overview.jpg|thumb|Completed unit in 2018.]]

[[File:Geiger-schematic.png|thumb|Schematic]]

A Geiger counter has been on my list of projects for a while, and in Spring 2018 I made one based on the very available Russian SBM-20 Geiger-Muller tubes, one of the most common cheap tubes on Ebay.

The heart of the Geiger counter is the GM tube, which is a tube filled with gas, and two electrodes. A high voltage is applied to the tube, usually around 400 volts. When a particle of ionizing radiation passes through the tube, it will ionize a molecule of the gas, and allow a tiny bit of current to flow through the tube. If we can detect the tiny current that flows through the tube, we can count them and find out the rate of radiation exposure in the area.

==Hardware==
Since it has been a while since building, I don't have a full schematic ready. But briefly:
* The GM tube is a SBM-20. It can measure beta and gamma radiation. A resistor of several megaohms is placed in series to protect the tube from excessive current flow.
* An ATTiny84 microcontroller controls the HV power supply, counting, and user interface.
* The pulse detection circuit is made from a couple resistors, capacitors, and transistors, and comes from one of the common Geiger kit plans available online.
* The power supply is a boost converter made from an inductor being repeatedly shut off, which creates high voltage spikes. A diode rectifies the high voltage and stores it in a capacitor. A voltage divider allows the microcontroller to read the high voltage. Signal to the boost converter is supplied by the microcontroller, at about 8kHz. PWM on this 8khz signal controls the output voltage. The ATTiny provides a feedback control system, which is an I (integral) controller, which I found was quite stable. I also tried a P controller and PI controller, but I could not tune these as well.
* Power is supplied by an 18650 battery.

===Case===
The outside of the case has all user controls, inputs and outputs.
* On the left side of the case, there are two switches:
** Top Switch - When pulled towards front face, will enable internal speaker to provide Geiger "clicks"
** Bottom Switch - When pulled towards face, will hold Center button down. I originally planned to use this for an extra user interface item, but ran out of IO.
* On the front face:
** 7 segment display - showing all the user interface operations
** Blue LED - Turns on when high counts of radiation are observed
** Buttons, '''C'''enter, '''L'''eft, and '''R'''ight. These are the main interface controls.
* On the right side:
** 3.5 mm jack - provides Gnd, radiation pulse output, and serial output from the microcontroller
** Barrel connector - Connect 3.7V - 5V here for external power. Center positive.
** Microusb - Connect USB to charge battery. It should not be used to run the system, probably.
** Power switch - Switches between battery power and external power barrel connector.
====2019 redesign====
The first case was very brittle ever since it came off the printer, and it eventually broke apart. I had made some more successful case designs for my other projects since then, and I decided to make a new case.
* I removed the segmented interior, so that the different components could be set into the case without the trouble of running wires through a bunch of different holes.
* Removed the switch that hold the center button down. Why did I need it.
* Added screw holes to hold the switches in place with bolts instead of hot glue.
* Placed all controls and ports on right side.
** Bottom switch is power switch
** Top switch is speaker on/off
** The USB port is now used to power the device when charging, just like on the [[Model T speedometer]]. This replaces the barrel power connector.
** Replaced the 1/8" jack with a 5 pin connector which connects to the ISP port (without VCC). This port can be used to program the ATTiny without opening the case, and the pins can be programed for other uses to get count data out.

==Software / Operator interface==
The Geiger counter is controlled mainly through the three buttons on the front of the unit.
* The '''right''' button is the '''Mode Select''' button. Pressing this button will advance to the next mode. While pressed, it will display the number of the mode that will be active upon release.
* The center button is used as the main Alt/alternate button. This is used because not all information can be displayed in just 4 digits.
* The left button is either a second alternate button or a reset button.

===Modes===
There are '''10''' modes in the current system:
* 0 - Counts per minute, calculated over 1 minute.
** '''C'''enter button - Displays seconds of the frame (0 to 59). When the number has rolled over back to where it was, one minute has passed, and a complete set of new data has been read.
** '''L'''eft button - Resets count.
* 1 - MicroSiverts per hour, calculated over 1 minute. Displays as a float, yyyy.xxxx (ie 0001.251 or 1.251 uS/h. With no buttons pressed, the display shows digits after the decimal point (xxxx)
** C - display high digits of number (yyyy).
* 2 - Counts per hour, calculated over 1 hour. Displays as integer (yyyyxxxx). Normally displays values up to 9999 (the xxxx digits)
** C - display high digits of number (yyyy).
** L - display current minute of frame (0 to 59).
* 3 - MicroSiverts per hour, calculated over 1 hour. Same display format as mode 1. Normal display is digits after decimal point.
** C - high digits of number (before decimal place).
* 4 - Total count. Display is an integer like mode 2.
** C - display high digits of integer.
** L - RESET this counter.
* 5 - Threshold to turn on blue LED. When counts/min are more than this value, blue light will turn on.
** C - doubles threshold value
** L - halves threshold value
* 6 - LED display brightness
** C - Increment value
** L - Decrement value
* 7 - Display voltage of HV power supply (in Volts)
** C - displays analogRead() value of HV read. (0-1023)
** L - displays pwm out value (0-255)
* 8 - Displays battery voltage (in Volts *100)
** C - displays analogRead() value of battery reading.
* 9 - Display 4 lower "random" bits
** C - displays decimal representation of 8 random bits (0 to 255).

==Files==
*[[File:Geiger-sketch.zip]] - Arduino sketches (attiny)
*[[File:Wilson-geiger-pcb-v1.zip]] - Eagle and gerber files for a PCB

2020-12-10T14:32:38Z

Alnwlsn: Created page with "placeholder"

placeholder

RC Wheelchair 3

2020-09-03T17:25:25Z

Alnwlsn:

2020-05-20T12:34:53Z

Alnwlsn: /* Project List */

'''This site''' serves documentation for my various projects, mostly for my own reference, but also as a way to share them. Using a wiki for this purpose is certainly overkill, but it is easy to edit and format, and I am familiar with it. Whenever I do a fairly involved project, there's a decent chance I will write up the things I learned on this site. As it stands, this site is still relatively sparse, because I like working on projects more than writing about them, like most people.

This web server and the content it provides is also a project in and of itself. This is running on server hardware and software that I set up myself, so as such even the content you are reading now is experimental. I guarantee no stability or reliable access, although I will do my best to keep this available online for as long as possible (though as of 2020 I have had a server like this running continuously for over 5 years).

==Project List==
More major projects are listed below, in no particular order. See the list of [[Special:AllPages|all pages here.]]

* [[AWOL Box]] - My take on the infamous Mikal Hart Reverse Geocache™ puzzle
* [[Nixie Clock 1]] - First completed Nixie clock/display unit
* [[Nixie Clock 2]] - Second Nixie display
* [[RC Wheelchair 1]] - Hacking the joystick of an electric wheelchair for remote control
* [[RC Wheelchair 2]] - A complete high-power h-bridge controller, controls, and radio system.
* [[Wilson X carriage]] - Improved x-carriage for the Prusa i3 style 3d printer.
* [[COW arm]] - a robot arm for the wheelchair robot base
* [[Lora module]] - module that makes using LoRa radio communications easier to work with.
* [[Environmental logger]] - A time capsule experiment
* [[Model T speedometer]] - General purpose GPS based speedometer for cars that don't have one.
* [[Geiger counter]] - my homemade Geiger counter using a SBM20 tube
* [[Raspberry Pi DVR]] - my main way of recording TV off the air
* [[Wilson Tetris]] - my version of a Tetris clone (in C)
* [[Door monitor]] - putting an unused security system to "good" use.
* [[uScreen]] - general purpose module with esp8266 and Nokia LCD
* [[6888 Transmitter]] - 6888 tube-based AM transmitter
* [[Sky Pointer]] - a thingy for pointing out objects in the sky.
* [[Atlas Gears]] - Replacement lathe/mill changegears
* [[Smart Response XE]] - Hacking of a school response system
* [[Floppy disk drive hacking]] - Poking around floppy drives with a logic analyzer
* [[Coronameter]] - Dedicated screen for pandemic panicking.
* [[Miscellaneous]] - short things that aren't long enough for their own page
* [[Unpublished Projects]]

==TRS-80 Stuff==
* [[TRS-80 Model 1 - Character ROM]]
* [[TRS-80 Model 1 - Wilson Expansion Interface]] - an Expansion Interface (needed to connect floppy drives and other peripherals to the 1977 TRS-80 microcomputer)
* [[TRS-80 Plug 'n Power Controller]] - reverse engineering an extinct trs-80 accessory

==Other Services==
This server has hosted a number of different things since it's original incarnation in high school. Some of the old services are still up (but others are unlisted or taken down due to spam or security risks)

* [http://alnwlsn.ax.lt/lists/ Public Lists] - experimental spam collection
* [http://alnwlsn.ax.lt/wintercamp/notifier/ Winter Camp Notifier Script] - service that emails you when new Winter Camp discussion takes place
* [http://alnwlsn.ax.lt/wicm/index.php/Main_Page WICM] - A copy of the Winter Camp encyclopedia translated into MediaWiki

===What is the fish?===
The green fish is from a game I made when I first learned how to program. Over time, it turned into the logo that I use for my projects.

Main Page

2020-05-20T12:31:50Z

Alnwlsn: /* What is the fish? */

'''This site''' serves documentation for my various projects, mostly for my own reference, but also as a way to share them. Using a wiki for this purpose is certainly overkill, but it is easy to edit and format, and I am familiar with it. Whenever I do a fairly involved project, there's a decent chance I will write up the things I learned on this site. As it stands, this site is still relatively sparse, because I like working on projects more than writing about them, like most people.

This web server and the content it provides is also a project in and of itself. This is running on server hardware and software that I set up myself, so as such even the content you are reading now is experimental. I guarantee no stability or reliable access, although I will do my best to keep this available online for as long as possible (though as of 2020 I have had a server like this running continuously for over 5 years).

==Project List==
More major projects are listed below, in no particular order. See the list of [[Special:AllPages|all pages here.]]

* [[AWOL Box]] - My take on the infamous Mikal Hart Reverse Geocache™ puzzle
* [[Nixie Clock 1]] - First completed Nixie clock/display unit
* [[Nixie Clock 2]] - Second Nixie display
* [[RC Wheelchair 1]] - Hacking the joystick of an electric wheelchair for remote control
* [[RC Wheelchair 2]] - A complete high-power h-bridge controller, controls, and radio system.
* [[Wilson X carriage]] - Improved x-carriage for the Prusa i3 style 3d printer.
* [[COW arm]] - a robot arm for the wheelchair robot base
* [[Lora module]] - module that makes using LoRa radio communications easier to work with.
* [[TRS-80 Model 1 - Character ROM]]
* [[TRS-80 Model 1 - Wilson Expansion Interface]] - an Expansion Interface (needed to connect floppy drives and other peripherals to the 1977 TRS-80 microcomputer)
* [[TRS-80 Plug 'n Power Controller]] - reverse engineering an extinct trs-80 accessory
* [[Environmental logger]] - A time capsule experiment
* [[Model T speedometer]] - General purpose GPS based speedometer for cars that don't have one.
* [[Geiger counter]] - my homemade Geiger counter using a SBM20 tube
* [[Raspberry Pi DVR]] - my main way of recording TV off the air
* [[Wilson Tetris]] - my version of a Tetris clone (in C)
* [[Door monitor]] - putting an unused security system to "good" use.
* [[uScreen]] - general purpose module with esp8266 and Nokia LCD
* [[6888 Transmitter]] - 6888 tube-based AM transmitter
* [[Sky Pointer]] - a thingy for pointing out objects in the sky.
* [[Atlas Gears]] - Replacement lathe/mill changegears
* [[Smart Response XE]] - Hacking of a school response system
* [[Floppy disk drive hacking]] - Poking around floppy drives with a logic analyzer
* [[Coronameter]] - Dedicated screen for pandemic panicking.
* [[Miscellaneous]] - short things that aren't long enough for their own page
* [[Unpublished Projects]]

==Other Services==
This server has hosted a number of different things since it's original incarnation in high school. Some of the old services are still up (but others are unlisted or taken down due to spam or security risks)

* [http://alnwlsn.ax.lt/lists/ Public Lists] - experimental spam collection
* [http://alnwlsn.ax.lt/wintercamp/notifier/ Winter Camp Notifier Script] - service that emails you when new Winter Camp discussion takes place
* [http://alnwlsn.ax.lt/wicm/index.php/Main_Page WICM] - A copy of the Winter Camp encyclopedia translated into MediaWiki

===What is the fish?===
The green fish is from a game I made when I first learned how to program. Over time, it turned into the logo that I use for my projects.

WTERM

2020-05-20T03:45:42Z

Alnwlsn: /* Files */

WTERM

2020-05-20T03:45:05Z

Alnwlsn:

'''WTERM''' is my own TRS-80 terminal emulator (written in Z80 Assembly), for use with my recently completed RS232 adapter. Although the RS232 board I wired up is 100% compatible with the true Radio Shack offering, and works as such, the software was a bit lacking. I tried out a couple programs for using the RS232 port (Omniterm and Matrix ALgorithim), and found a few problems for the things I wanted to do (connect to a Linux box and work with the command line):

* No cursor control. I want an ability to put the cursor anywhere on screen (Ok, so Omniterm does have this, but it has its share of other problems).
* CR and LF are both the same. This is a big one - on pretty much any other terminal, these have 2 different purposes. CR makes the cursor move to the start of the line, and LF makes the cursor move one row/line down (and stays at the same column). The existing programs presumably use the TRS-80 ROM routines to drive the screen, and I don't think it has these features. Instead, both an LF or CR will make the cursor move to the start of the next line. This is a problem for Linux, which always sends CRLF. Even after editing the terminfo source to try to turn one of these signals off, it seems as though it's baked in. Some of the terminal programs like Omniterm try to suppress LF in a CRLF, but I found it doesn't work very well. Some Linux programs will send one or the other, fully expecting standard usage.
* Too slow. The TRS-80 is only 1.77 mhz, and the RS232 does not use interrupts. So, anything that happens which is not reading the RS232 data stream in means that bytes can be missed from the data stream. In particular, scrolling the screen upwards in most existing programs seems to use the ROM routines, during which time the UART cannot be read, and we might clip a few letters from a word. Therefore, most terminal programs can only do 600 baud maximum, because any faster and some data will be lost during the time it takes the screen to scroll upwards.
* No handshaking. RTS/CTS are not used for anything. In most programs they are toggleable for general purpose, but not for handshaking. Omniterm is supposed to support XON/XOFF though.

==WTERM==
My version roughly emulates a DEC VT-52 (the predecessor to the VT-100). I implemented the ESC codes for moving the cursor around, homing, and clearing stuff, which is most of them. There's no need to do alternate fonts or inverted colors; the TRS-80 character generator is fixed in a ROM. The rest is just fixing the issues discussed previously:

* Custom routines for drawing on the screen, and reading the keyboard. No ROM routines, I access the hardware directly. Not sure if these are any quicker, but by not being in ROM I can put extra stuff inside - between writes onto the screen, and between every keypress, I can read the UART to see if we got new data, meaning nothing gets missed. Also, thanks to these routines:
** Custom keyboard map. I use the CLEAR, SHIFT and BREAK keys as modifiers. It is possible you type every single ASCII code 0-127. Enter is the only key handled separate (it just sends CR).
** CR and LF now do their standard functions, thanks to custom cursor control routines.
** It should be possible to operate WTERM without a TRS-80 ROM installed. (Why or how you would do this I'm not sure).
* Circular buffers on UART input and output. The keyboard probably doesn't need a buffer (nobody can type that fast), but the input buffer helps us collect the data quickly when we are doing something else like scrolling the screen or reading a key. Then, when we are not doing anything, we can work on the data we just collected.
* Hardware flow control - When the buffer gets close to full, the RTS pin goes OFF. When it empties most of the way, it turns it back on. Simple and easy, but missing from existing programs. Why would I spend all that time building up a RS232 board if these signals are never used?
* Faster. Wterm can keep up with updating the screen at 1200 baud, which is fast enough to not feel excruciatingly slow, and makes things pretty usable.

WTERM is probably not perfect (this is only the 2nd/3rd assembly program I have ever written!) but at least it makes the TRS-80 act like a more standard terminal.

==Files==
[[File:Wterm.zip]] - source and binary. Note that in here it's called "a". I use this to quickly compile and test my program:
1. Compile with yaza z80 compiler
2. Convert binary to Intel hex with a Python bin2hex program (I didn't write it, it comes as an example for the bin2hex module)
3. Modify Intel Hex with the correct entry point
4. Convert to CMD file using George Phillips's trld converter program
5. Import the file onto a DOS disk image, already pre-configured to execute "a.cmd" on startup
6. Start trs80gp emulator with the disk in drive 0.

The included batch file does all of this within about 3 seconds, making it a very quick way to test my programs after making minor changes. Note that you will need the above programs to do it, though.

Main Page

2020-05-20T03:34:52Z

2020-03-25T02:51:01Z

Alnwlsn: /* RS-232 board - 3-24-2020 */

[[File:Trs80ei2-proto.jpg|thumb|Completed prototype featuring extra RAM, SD and DD floppy controllers, RTC heartbeat, SD Card and shared 0x3000 RAM]]
The '''TRS-80 Model 1''' originally comprised just the keyboard unit (containing the cpu, video diver, keyboard, cassette reader circuitry and 16k or ram) and monitor. Later, Radio Shack introduced the '''Expansion Interface (EI)''', which was another unit that sat behind the keyboard and added up to 32K more ram, a floppy disk controller, and some extra logic to control a printer or other accessories. Other features could be added to the expansion interface, including a doubler that added extra capacity to floppy disks or an rs232 board.

When I got my first TRS-80 in 2018, all I got was the keyboard. I had to make my own adapters to connect a standard NTSC monitor, cassette recorder, and I even rewound a transformer to provide the combination of different voltages that the TRS-80 needs for power. However, since I eventually wanted to add more memory and run some of the DOS operating systems; this meant I would have to come up with an Expansion Interface. Unfortunately, most of the original EIs online, even ones that could not be confirmed working, were priced higher than I originally bought the keyboard. The schematics for the EI are in the Radio Shack Service manuals, which are easily found online, and the EI is made using almost entirely using 74 series logic. Since I happened to have a large stock of 74 logic chips and some prototyping boards, I decided to make my own EI. Doing this would also allow the freedom to change the wiring around for experiments while not destroying a piece of irreplaceable vintage hardware.

==Overview==
[[File:Ei2-block-diagran.png|thumb|Block diagram of my EI so far]]
My EI contains:

* Blinkenlights - Connected to address bus, data bus, and control signals.
* 32K RAM (using a 128K SRAM chip because that's what I happened to have; the rest is not yet used)
* INS1771N floppy disk controller for FM encoded disks (fully compatible with the original FD1771 in a real EI, can therefore read the nonstandard DAM records used by TRSDOS)
* WD2793 floppy controller for MFM encoded disks, set up like a Percom Doubler<ref>[http://www.trs-80.org/percom-doubler/ Percom Doubler]</ref> but this particular chip also has good internal data separation too, saving a few chips.
* 1K dual port SRAM, placed at TRS-80 memory address 0x3000-0x33ff, which is unused address space in a normal Model 1 system. This ram is shared between the trs80 and the atmega microcontoller.
* ATMEGA1284p microcontroller, running the [https://github.com/MCUdude/MightyCore Mightycore] bootloader; this makes it compatible with and able to be programmed by Arduino software.
* SD card, connected to Arduino

Things not covered yet are:
* Printer port
* TRS-80 RS232 port
* Screen printer port
* Extra cassette port / switch

==Theory of operation / Features==
[[File:Trs80ei2-address-decoder.PNG|thumb|Simulation of prototype address decoder / glue logic]]
Most of my system works like a normal EI, at least as far as the floppy controllers and extra system memory goes. I mainly drew inspiration for the wiring from the TRS-80 technical manuals and schematics. In this version, some sections are taken verbatim from the original schematics, like the six chips used for the clock divider. I found a design for a double density disk adapter in an old copy of Northern Bytes<ref>Northern Bytes, Volume 7, Number 5[https://archive.org/details/Northern_Bytes_Volume_7_Number_5_1985_Alternate_Source_Information_Outlet_The_US]</ref>. However, the address decoding and buffering logic is my own design, done with 74 series logic. Programmable logic might make things more compact, but there is a steep learning curve (I have not found anything like Arduino for programmable logic) and the PAL devices I have are no longer in manufacturing. Besides, traditional 74 series logic seems to fit better with the spirit of the project.

I have not implemented any power supply for the board, just some filtering; because I needed a standard ATX power supply to drive floppy drives, I decided to use the +5, -5, and +12 volt supplies from that instead.

===ATMEGA Section===
The special new features come from the combination of the dual port RAM and ATMEGA microcontroller. A few TRS-80 projects I have looked at place some extra memory at TRS-80 address 3000H (which is otherwise completely unused in a stock machine), for extra code or other features. I have placed a Dual port RAM at this location, which means the TRS-80 can read, write, and execute code at this section, adding an extra 1K of general purpose RAM to the system. However, this is dual port RAM, meaning that it can be accessed by two devices '''at the same time'''. I connected the other side of the dual port RAM to an ATMEGA1284P, which is a modern microcontroller which runs at 16MHz and has 16K ram, an impressive system in it's own right when compared to the TRS-80. The microcontroller has an attached SD card for tons of space for storage, and its own operating system, with the express goal of monitoring and managing the shared memory section.

My additions to the TRS-80 are broken down into two programs:
*'''SH'''ared '''R'''am '''I'''nterface '''P'''rogram - a short z80 program that the TRS-80 runs from the shared dual port RAM
*'''A'''tmega '''C'''ontrol '''P'''rogram '''T'''erminal - the Arduino sketch that runs on the Atmega, and provides a whole host of functions to read, write and modify data and access hardware on the TRS-80 (via SHRIP).

ACPT command-line functions include:
* Local (shared dual port RAM) memory functions, which directly change data on the shared RAM. Addresses for these commands range from 000-3ff.
** <code>ls</code> - display entire contends of RAM (in hex editor-like grid)
** <code>lr haddress</code> - reads single byte
** <code>ll file.bin hstartaddress</code> - load a dump file to RAM, starting at the given address
** <code>ld file.bin hstartaddress hendaddress</code> - dumps a section of memory to a file on the SD card
* TRS-80 memory functions, working through the monitor program on the shared memory. It must be running for these to work.
** <code>rs hstartaddress hendaddress</code> - works like ls, but you can spec sections of Z80 memory instead of the whole thing.
** <code>lr / ll / ld</code> - work like their local ram equivalents, but now the address range is the whole Z80 address space: 0000-ffff
** <code>j address</code> - jump to code at ''address''
** <code>r</code> - exit the monitor program and Return to normal TRS-80 functioning.
** <code>p</code> - Pause the TRS-80 and run the monitor code.
** <code>rv file.bin hstartaddress</code> - verify a file matches a section of RAM
* SD file commands, special for managing files on the SD card.
** <code>dir</code> - shows list of files and their sizes
** <code>del file.bin</code> - delete a file
* File send/receive. Using a special terminal program like teraterm, you can transfer files to and from the SD card without turning off the system and taking it out. There is no special protocol (like XMODEM); files are just sent as raw binary streams.
** <code>xs file.bin</code> - send raw file over serial port. If you log these bytes, you can reconstruct the file.
** <code>xr file.bin</code> - receive raw file over serial port. Using a terminal program with xon/xoff, send the binary file.

This is all well and good, but SHRIP can only work when the Z80 cpu is running the code, stored inside the shared RAM. One way to get to it is to type SYSTEM ↵ / 12288 ↵ from BASIC to start executing code from address 3000H. But, it sure would be nice to be able to use the monitor program whenever I want, without typing in anything. If I am in DOS or inside a program, there's no way to make the Z80 jump to address 3000H without exiting it. To this end, I decided to modify the TRS-80 ROM. I had already placed an EPROM inside the TRS-80 case to update to the R/S ROM version. I replaced the routine at 002BH with a jump to 3000H. The replaced routine is the part that detects which key is pressed on the TRS-80 keyboard, meaning that it gets run all the time. We can place the rest of the 002BH code at the end of SHRIP, so it can get back to normal operation if we aren't using any SHRIP functions.

Being in the middle of the keyboard routine, the monitor program also has the opportunity to return alternate data than what the keyboard is actually doing. The monitor program checks a byte of shared ram at address 3306H, and if it is nonzero, it will return that value as if the keyboard typed it. This means we can use the microcontroller to type things on the TRS-80 without ever touching the keyboard. I implemented two commands on the microcontroller command line interface to do this:
* <code>k sometext-to-type</code> - everything after the "k " is typed on the TRS-80 keyboard.
**It also works with escape characters, like <code>\n</code> for eNter and <code>\k</code> for breaK, <code>\u \d \l \r</code> for the direction keys, and <code>\c</code> for the clear key.
* <code>ks file.txt</code> - an entire file on the SD card is typed out over the keyboard. Escape characters aren't used here, it just sends the file as if it were a sequence of keyboard scan codes (most of the keyboard is ASCII).

====Files====
Revision 6 - [[File:Trs80ei2-v6.zip]]

Revision 7 - [[File:Trs80ei2-v7.zip]]

==Hardware/Construction==
I constructed this on protoboard. Many of these types of projects use wire wrapping, but I don't have any wire wrapping sockets or any tools for doing this. Instead, I used the wire wrap-esque technique where wires jump to different points on the bottom of the board, and are soldered in place. This looks incredibly messy, and it is extremely easy to burn existing wires with the iron (if you look closely, you can see where I have fixed burnt wires with liquid electrical tape.) However, this technique does allow for a comparatively high chip density on the board, because none of the PCB area is used to carry signals.

Most of my chips are socketed, as pretty much all of them are either very old and fragile, or new and very cheap and of questionable quality. The sockets make it very easy to fix bad chips, especially since the bottom of these sockets usually have a separate, free wire on most of the pins.

On most of my chips, I have applied a label, making it easy to see the function on every pin. I make my labels using a thermal printer that was originally used to print price stickers in a store. The type of thermal labels used will turn black when they get hot. I have used this property more than once to detect a bad chip on my board (the chips often heat up when they go bad).
<gallery>
trs80ei2-base-bottom.jpg|base-bottom
Trs80ei2-base-top.jpg|base-top
Trs80ei2-doubler-bottom.jpg|doubler-bottom
Trs80ei2-doubler-top.jpg|doubler-top
Trs80ei2-floppy-bottom.jpg|floppy-bottom
Trs80ei2-floppy-top.jpg|floppy-top
Trs80ei2-lights-top.jpg|lights-top
Trs80ei2-lights-bottom.jpg|lights-bottom
</gallery>

==Log==
===Debugging a bad RAM chip - May 31, 2019===
While running the TRS-80 today, I noticed that I was not able to read files reliably under LDOS, but DoubleDos worked just as well as ever. I know that I had LDOS working when I first completed the expansion interface, so something was clearly wrong. Upon further investigation, I noticed that the errors only occurred when the double density driver (FDUBL) was loaded in LDOS. When the driver was loaded, I experienced complete instability when trying to read disks, and I could not format double density disks at all; the system would simply hang instead of stepping the disk drive. Initially, I thought there might be something wrong with my doubler board, after all, it does sit on top of the stack of boards and is slightly crooked. But, double density still worked fine under DoubleDos, so this was probably not the issue.

My next thought was some kind of ram problem. I did notice that when loading data directly to ram with my Atmega monitor program, I noticed some verify errors at system address 0xb300. At first, I thought that this might be a stack pointer that was getting overwritten, but then I remembered that my monitor places it's stack within the shared 1k RAM. I tried directly writing to 0xb300 and could not get a consistent write, though the bytes before and after it worked fine. Could this verify error be the problem? This section of system memory would be within the 32K of SRAM provided by my expansion board. I am using a 128K chip here because that's what I had, but the chips I have are not credibly sourced, and I have had problems in this board with clone chips of 74 logic.

I tried replacing the RAM and the problem did indeed go away, and I was finally able to fully load entire (48K) ram snapshots using my monitor program with no verify errors. At the same time, I found LDOS once again able to read and write disks reliably. So it seems that the ram was bad, although I find it strange that only a single byte was affected.

===FreHD clone experiment - June 3, 2019===
Before I had completed the floppy controllers, I had began work on a frehd clone that would fit on my weird stacked EI, which I could never get to work properly. Developed by Frederic Vecoven, The [http://www.vecoven.com/trs80/trs80.html frehd project is an open source project] that emulates a hard drive in a manner consistent with the original mfm disk controllers you could get back in the day, though there is [http://members.iinet.net.au/~ianmav/trs80/emulator.htm now a closed source version assembled and sold] by Ian Mavric of Australia. After getting all my floppy drives working, having two floppy drives simulated with Goteks (more on this later), I really don't need a frehd too, but I had already made the board (following the schematic in the original frehd open source release), and so it was worth another try.

My first experiment was to try a program called [http://48k.ca/trsvid.html TRSVID] (developed by George Phillips) which can display full motion video on the trs-80 using a frehd, although you need to change the firmware on the frehd PIC microcontroller first. Having constructed the entire board myself, I had a programmer too in order to program the PIC in the first place, and after loading the Phillips firmware, I too was able to watch grainy videos on my TRS-80, with equally crummy sound. Although the quality isn't great by modern standards, this is an extremely impressive demo considering the TRS-80's age. You only need to look at [[Wilson Tetris|my Tetris program]] to see the normal limitations of the TRS-80 graphics.

However, I ran into trouble when trying to actually use my clone frehd for its intended purpose: as a hard drive. The freHD comes with some utilities to help mount and create hard disks, and <code>VHDUTL</code> seems to work ok. However, trying to actually format the disks using <code>RSHARD1</code> (using 840 tracks, 6 heads and 140 sectors), gave mixed results. Sometimes, the system would lock up after I finished filling out the prompts to mount the disk using <code>SYSTEM (DRIVE=4,DISABLE,DRIVER="RSHARD1")</code> Other times, it would lock up after trying the <code>RSFORM1</code> program which is supposed to format the disk. Most of the time though, these commands would work successfully, even verifying the format correctly. But, I found that afterwards, the system might lock up when trying to display the directory.

In the event that all of the above setup works properly, I was still left with one final problem, which is that when I copy a file to the emulated hard drive, it doen't always seem to be a complete copy. I could copy my Tetris program and get it to load at least once or twice, but my other version (Metris, with more pieces) would not run no matter what I tried. Soon afterwards, my hard disk got corrupted and I would have to start all over.

Incidentally, I also noticed that the <code>IMPORT2</code> command which is used to transfer files from the freHD SD card to TRS-80 devices like floppy disks would also only make corrupt files. Perhaps if I examine the files, or make some test payloads, I may be able to determine what's going on, but that will need to wait for another day. I know that Ian made some changes the software, either to the frehd, trs-80 or both, to make the frehd work on a Model 1, but as of now I am not sure what those changes are.

It may be better to continue my ATMEGA/dual port ram solution anyway, as this has the advantage of modifying any memory location.

===Version 7 of software - June 19, 2019===
It seems like there is some kind of problem with the 32K ram on the board, most likely a bad connection or something, which is near impossible to find. I sometimes find that reseating the SRAM chip or swapping it for a diffrent one will usually work, even though all of my ram chips test good using my EPROM programmer as a tester.

Anyways, I decided I needed to add a RAM test feature to the atmega operator interface. Before this, I created two 48k files of all 1s (0xFF) and all 0s (0x00), which I would load each with the '''rl''' command, which verifies each byte as it is written, allowing me to find RAM errors. Since this is a rather long command to type out, I decided to include a command <code>tstram</code> that would write all 1s, then all 0s, for each ram address over the entire 48K ram. An optional number after the command will specify the number of loops to do, from once to a whole bunch.

Additionally, I discovered a bug that would not allow the 3rd noun to be counted, making all commands think that there were only 2 nouns maximum (nouns=parameters after the command), making commands like <code>rd</code> inoperable. As a workaround for v7, I increased the allowed number of nouns to 4, which means that we still have the same error, but now the parser thinks that we can't have more than 3 nouns, which is the most that any command has. I will fix this properly in the next releases.

===v9 - Aug 2019===
Since the last log entry, I have indeed found the cause of the RAM issue - an address pin (one of the high address pins that isn't used) was left floating! This means that the ram would randomly switch to a different bank; this would be as if the ram randomly erases everything sometimes.

The reason I discovered this was because I wired these extra address pins to some atmega pins, for an experiment. Now, through the Atmega, I can switch the 32k of system ram between 4 banks.

I also am experimenting with an on-board terminal for the Atmega terminal control interface. From the little z80 program running in the dual port RAM, we already have access to the TRS-80 keyboard. To get access to the screen, we can call address 0x033a, which writes the character in A onto the screen, then advances the cursor. There are a few other routines <ref>http://www.trs-80.org/trs-80-rom-routines-documented/</ref> that can help manage the screen, so that makes things like advancing the cursor and scrolling down something that I don't need to implement myself in my own program. I added calls to these routines in SHRIP, meaning that SHRIP-ACPT can now write stuff directly to the screen. I even added extra functions to the ACPT sketch, to make the Arduino stream functions like Serial.print also write to the TRS-80 screen.

Ok, so we now have access to the TRS-80 screen and keyboard. The last step is to make ACPT available on the TRS-80 directly, without needing to use an extra serial terminal on the Atmega. I added a keyboard shortcut to SHRIP, which will enter into an on-screen ACP terminal. All I need to do is first copy the contents of the screen and save the cursor position so I can get back exactly where I left off. I store the image data in one of the extra banks of SRAM, since it is literally wasted space until now. When I'm done with the terminal, I issue the exit command, and the screen data is copied back onto the screen.

This means it is now possible to load machine code directly from the Atmega SD card into trs-80 memory, and execute it, without ever hooking up the trsei2 board to another computer. You can't really load full ram images yet, because the onscreen terminal itself uses some of the system RAM, but overall, the system is much more accessible now.

===v12 - December 2019===
With 128K of SRAM on the expansion board, it would really be nice if that extra ram could be accessed from the Z80 side of things, so that I don't have to go through the Atmega. This should also speed up assembly programs that use the extra RAM.
In the memory mapped IO section that breaks out address 37E0-37EC, I used 74LS138 octal decoders, so I also have lines for 37F0-37FC that are not used in a standard TRS-80. Therefore, I connected a 74LS175 latch to data pins D0-D1, and latch on writes to memory address 37FC. This makes the extra RAM (4 blocks of 32K, placed in the upper half of Z80 memory map) accessible from the Z80 directly.

Hardware also has a parallel port added, which is nothing more than a couple buffers and latches. I needed this to make the winter camp latrine monitor program, since I discovered that it needs a printer to work properly.

===RS-232 board - 3-24-2020===
The real expansion interfaces had an option for a RS-232 serial port, which enabled communication to the outside world; most modems required an RS232 port. Since I want to hook this up to a raspberry pi eventually, I'll need one.

The original board used a tr1602 UART and BR1941 as the baud rate generator. I couldn't find either of these chips, but I did find a TR1865 and COM8136, which are chips used in the Model 4, and are compatible. They also do not require a -5 or 12V supply, not that it's a big deal as I have an ATX supply as the power source. There's also a few supporting 74 series components, and some buffers to convert the 5V signals to the RS-232 voltages. In place of the buffers, I will try to use MAX232s instead, since I have a bunch of them for some reason.

For address decoding, I am trying a GAL22v10. Normally I don't like using GAL programmable logic, because these chips are no longer made (there's still a lot though), and they sort of obscure how everything works. In this case, I found myself short of 74 logic chips in the middle of a global pandemic, so why not try something else and replace 4-5 74 chips instead.

==References==
<references />

TRS-80 Model 1 - Wilson Expansion Interface

2020-03-25T02:18:48Z

Alnwlsn: /* Log */

[[File:Trs80ei2-proto.jpg|thumb|Completed prototype featuring extra RAM, SD and DD floppy controllers, RTC heartbeat, SD Card and shared 0x3000 RAM]]
The '''TRS-80 Model 1''' originally comprised just the keyboard unit (containing the cpu, video diver, keyboard, cassette reader circuitry and 16k or ram) and monitor. Later, Radio Shack introduced the '''Expansion Interface (EI)''', which was another unit that sat behind the keyboard and added up to 32K more ram, a floppy disk controller, and some extra logic to control a printer or other accessories. Other features could be added to the expansion interface, including a doubler that added extra capacity to floppy disks or an rs232 board.

When I got my first TRS-80 in 2018, all I got was the keyboard. I had to make my own adapters to connect a standard NTSC monitor, cassette recorder, and I even rewound a transformer to provide the combination of different voltages that the TRS-80 needs for power. However, since I eventually wanted to add more memory and run some of the DOS operating systems; this meant I would have to come up with an Expansion Interface. Unfortunately, most of the original EIs online, even ones that could not be confirmed working, were priced higher than I originally bought the keyboard. The schematics for the EI are in the Radio Shack Service manuals, which are easily found online, and the EI is made using almost entirely using 74 series logic. Since I happened to have a large stock of 74 logic chips and some prototyping boards, I decided to make my own EI. Doing this would also allow the freedom to change the wiring around for experiments while not destroying a piece of irreplaceable vintage hardware.

==Overview==
[[File:Ei2-block-diagran.png|thumb|Block diagram of my EI so far]]
My EI contains:

* Blinkenlights - Connected to address bus, data bus, and control signals.
* 32K RAM (using a 128K SRAM chip because that's what I happened to have; the rest is not yet used)
* INS1771N floppy disk controller for FM encoded disks (fully compatible with the original FD1771 in a real EI, can therefore read the nonstandard DAM records used by TRSDOS)
* WD2793 floppy controller for MFM encoded disks, set up like a Percom Doubler<ref>[http://www.trs-80.org/percom-doubler/ Percom Doubler]</ref> but this particular chip also has good internal data separation too, saving a few chips.
* 1K dual port SRAM, placed at TRS-80 memory address 0x3000-0x33ff, which is unused address space in a normal Model 1 system. This ram is shared between the trs80 and the atmega microcontoller.
* ATMEGA1284p microcontroller, running the [https://github.com/MCUdude/MightyCore Mightycore] bootloader; this makes it compatible with and able to be programmed by Arduino software.
* SD card, connected to Arduino

Things not covered yet are:
* Printer port
* TRS-80 RS232 port
* Screen printer port
* Extra cassette port / switch

==Theory of operation / Features==
[[File:Trs80ei2-address-decoder.PNG|thumb|Simulation of prototype address decoder / glue logic]]
Most of my system works like a normal EI, at least as far as the floppy controllers and extra system memory goes. I mainly drew inspiration for the wiring from the TRS-80 technical manuals and schematics. In this version, some sections are taken verbatim from the original schematics, like the six chips used for the clock divider. I found a design for a double density disk adapter in an old copy of Northern Bytes<ref>Northern Bytes, Volume 7, Number 5[https://archive.org/details/Northern_Bytes_Volume_7_Number_5_1985_Alternate_Source_Information_Outlet_The_US]</ref>. However, the address decoding and buffering logic is my own design, done with 74 series logic. Programmable logic might make things more compact, but there is a steep learning curve (I have not found anything like Arduino for programmable logic) and the PAL devices I have are no longer in manufacturing. Besides, traditional 74 series logic seems to fit better with the spirit of the project.

I have not implemented any power supply for the board, just some filtering; because I needed a standard ATX power supply to drive floppy drives, I decided to use the +5, -5, and +12 volt supplies from that instead.

===ATMEGA Section===
The special new features come from the combination of the dual port RAM and ATMEGA microcontroller. A few TRS-80 projects I have looked at place some extra memory at TRS-80 address 3000H (which is otherwise completely unused in a stock machine), for extra code or other features. I have placed a Dual port RAM at this location, which means the TRS-80 can read, write, and execute code at this section, adding an extra 1K of general purpose RAM to the system. However, this is dual port RAM, meaning that it can be accessed by two devices '''at the same time'''. I connected the other side of the dual port RAM to an ATMEGA1284P, which is a modern microcontroller which runs at 16MHz and has 16K ram, an impressive system in it's own right when compared to the TRS-80. The microcontroller has an attached SD card for tons of space for storage, and its own operating system, with the express goal of monitoring and managing the shared memory section.

My additions to the TRS-80 are broken down into two programs:
*'''SH'''ared '''R'''am '''I'''nterface '''P'''rogram - a short z80 program that the TRS-80 runs from the shared dual port RAM
*'''A'''tmega '''C'''ontrol '''P'''rogram '''T'''erminal - the Arduino sketch that runs on the Atmega, and provides a whole host of functions to read, write and modify data and access hardware on the TRS-80 (via SHRIP).

ACPT command-line functions include:
* Local (shared dual port RAM) memory functions, which directly change data on the shared RAM. Addresses for these commands range from 000-3ff.
** <code>ls</code> - display entire contends of RAM (in hex editor-like grid)
** <code>lr haddress</code> - reads single byte
** <code>ll file.bin hstartaddress</code> - load a dump file to RAM, starting at the given address
** <code>ld file.bin hstartaddress hendaddress</code> - dumps a section of memory to a file on the SD card
* TRS-80 memory functions, working through the monitor program on the shared memory. It must be running for these to work.
** <code>rs hstartaddress hendaddress</code> - works like ls, but you can spec sections of Z80 memory instead of the whole thing.
** <code>lr / ll / ld</code> - work like their local ram equivalents, but now the address range is the whole Z80 address space: 0000-ffff
** <code>j address</code> - jump to code at ''address''
** <code>r</code> - exit the monitor program and Return to normal TRS-80 functioning.
** <code>p</code> - Pause the TRS-80 and run the monitor code.
** <code>rv file.bin hstartaddress</code> - verify a file matches a section of RAM
* SD file commands, special for managing files on the SD card.
** <code>dir</code> - shows list of files and their sizes
** <code>del file.bin</code> - delete a file
* File send/receive. Using a special terminal program like teraterm, you can transfer files to and from the SD card without turning off the system and taking it out. There is no special protocol (like XMODEM); files are just sent as raw binary streams.
** <code>xs file.bin</code> - send raw file over serial port. If you log these bytes, you can reconstruct the file.
** <code>xr file.bin</code> - receive raw file over serial port. Using a terminal program with xon/xoff, send the binary file.

This is all well and good, but SHRIP can only work when the Z80 cpu is running the code, stored inside the shared RAM. One way to get to it is to type SYSTEM ↵ / 12288 ↵ from BASIC to start executing code from address 3000H. But, it sure would be nice to be able to use the monitor program whenever I want, without typing in anything. If I am in DOS or inside a program, there's no way to make the Z80 jump to address 3000H without exiting it. To this end, I decided to modify the TRS-80 ROM. I had already placed an EPROM inside the TRS-80 case to update to the R/S ROM version. I replaced the routine at 002BH with a jump to 3000H. The replaced routine is the part that detects which key is pressed on the TRS-80 keyboard, meaning that it gets run all the time. We can place the rest of the 002BH code at the end of SHRIP, so it can get back to normal operation if we aren't using any SHRIP functions.

Being in the middle of the keyboard routine, the monitor program also has the opportunity to return alternate data than what the keyboard is actually doing. The monitor program checks a byte of shared ram at address 3306H, and if it is nonzero, it will return that value as if the keyboard typed it. This means we can use the microcontroller to type things on the TRS-80 without ever touching the keyboard. I implemented two commands on the microcontroller command line interface to do this:
* <code>k sometext-to-type</code> - everything after the "k " is typed on the TRS-80 keyboard.
**It also works with escape characters, like <code>\n</code> for eNter and <code>\k</code> for breaK, <code>\u \d \l \r</code> for the direction keys, and <code>\c</code> for the clear key.
* <code>ks file.txt</code> - an entire file on the SD card is typed out over the keyboard. Escape characters aren't used here, it just sends the file as if it were a sequence of keyboard scan codes (most of the keyboard is ASCII).

====Files====
Revision 6 - [[File:Trs80ei2-v6.zip]]

Revision 7 - [[File:Trs80ei2-v7.zip]]

==Hardware/Construction==
I constructed this on protoboard. Many of these types of projects use wire wrapping, but I don't have any wire wrapping sockets or any tools for doing this. Instead, I used the wire wrap-esque technique where wires jump to different points on the bottom of the board, and are soldered in place. This looks incredibly messy, and it is extremely easy to burn existing wires with the iron (if you look closely, you can see where I have fixed burnt wires with liquid electrical tape.) However, this technique does allow for a comparatively high chip density on the board, because none of the PCB area is used to carry signals.

Most of my chips are socketed, as pretty much all of them are either very old and fragile, or new and very cheap and of questionable quality. The sockets make it very easy to fix bad chips, especially since the bottom of these sockets usually have a separate, free wire on most of the pins.

On most of my chips, I have applied a label, making it easy to see the function on every pin. I make my labels using a thermal printer that was originally used to print price stickers in a store. The type of thermal labels used will turn black when they get hot. I have used this property more than once to detect a bad chip on my board (the chips often heat up when they go bad).
<gallery>
trs80ei2-base-bottom.jpg|base-bottom
Trs80ei2-base-top.jpg|base-top
Trs80ei2-doubler-bottom.jpg|doubler-bottom
Trs80ei2-doubler-top.jpg|doubler-top
Trs80ei2-floppy-bottom.jpg|floppy-bottom
Trs80ei2-floppy-top.jpg|floppy-top
Trs80ei2-lights-top.jpg|lights-top
Trs80ei2-lights-bottom.jpg|lights-bottom
</gallery>

==Log==
===Debugging a bad RAM chip - May 31, 2019===
While running the TRS-80 today, I noticed that I was not able to read files reliably under LDOS, but DoubleDos worked just as well as ever. I know that I had LDOS working when I first completed the expansion interface, so something was clearly wrong. Upon further investigation, I noticed that the errors only occurred when the double density driver (FDUBL) was loaded in LDOS. When the driver was loaded, I experienced complete instability when trying to read disks, and I could not format double density disks at all; the system would simply hang instead of stepping the disk drive. Initially, I thought there might be something wrong with my doubler board, after all, it does sit on top of the stack of boards and is slightly crooked. But, double density still worked fine under DoubleDos, so this was probably not the issue.

My next thought was some kind of ram problem. I did notice that when loading data directly to ram with my Atmega monitor program, I noticed some verify errors at system address 0xb300. At first, I thought that this might be a stack pointer that was getting overwritten, but then I remembered that my monitor places it's stack within the shared 1k RAM. I tried directly writing to 0xb300 and could not get a consistent write, though the bytes before and after it worked fine. Could this verify error be the problem? This section of system memory would be within the 32K of SRAM provided by my expansion board. I am using a 128K chip here because that's what I had, but the chips I have are not credibly sourced, and I have had problems in this board with clone chips of 74 logic.

I tried replacing the RAM and the problem did indeed go away, and I was finally able to fully load entire (48K) ram snapshots using my monitor program with no verify errors. At the same time, I found LDOS once again able to read and write disks reliably. So it seems that the ram was bad, although I find it strange that only a single byte was affected.

===FreHD clone experiment - June 3, 2019===
Before I had completed the floppy controllers, I had began work on a frehd clone that would fit on my weird stacked EI, which I could never get to work properly. Developed by Frederic Vecoven, The [http://www.vecoven.com/trs80/trs80.html frehd project is an open source project] that emulates a hard drive in a manner consistent with the original mfm disk controllers you could get back in the day, though there is [http://members.iinet.net.au/~ianmav/trs80/emulator.htm now a closed source version assembled and sold] by Ian Mavric of Australia. After getting all my floppy drives working, having two floppy drives simulated with Goteks (more on this later), I really don't need a frehd too, but I had already made the board (following the schematic in the original frehd open source release), and so it was worth another try.

My first experiment was to try a program called [http://48k.ca/trsvid.html TRSVID] (developed by George Phillips) which can display full motion video on the trs-80 using a frehd, although you need to change the firmware on the frehd PIC microcontroller first. Having constructed the entire board myself, I had a programmer too in order to program the PIC in the first place, and after loading the Phillips firmware, I too was able to watch grainy videos on my TRS-80, with equally crummy sound. Although the quality isn't great by modern standards, this is an extremely impressive demo considering the TRS-80's age. You only need to look at [[Wilson Tetris|my Tetris program]] to see the normal limitations of the TRS-80 graphics.

However, I ran into trouble when trying to actually use my clone frehd for its intended purpose: as a hard drive. The freHD comes with some utilities to help mount and create hard disks, and <code>VHDUTL</code> seems to work ok. However, trying to actually format the disks using <code>RSHARD1</code> (using 840 tracks, 6 heads and 140 sectors), gave mixed results. Sometimes, the system would lock up after I finished filling out the prompts to mount the disk using <code>SYSTEM (DRIVE=4,DISABLE,DRIVER="RSHARD1")</code> Other times, it would lock up after trying the <code>RSFORM1</code> program which is supposed to format the disk. Most of the time though, these commands would work successfully, even verifying the format correctly. But, I found that afterwards, the system might lock up when trying to display the directory.

In the event that all of the above setup works properly, I was still left with one final problem, which is that when I copy a file to the emulated hard drive, it doen't always seem to be a complete copy. I could copy my Tetris program and get it to load at least once or twice, but my other version (Metris, with more pieces) would not run no matter what I tried. Soon afterwards, my hard disk got corrupted and I would have to start all over.

Incidentally, I also noticed that the <code>IMPORT2</code> command which is used to transfer files from the freHD SD card to TRS-80 devices like floppy disks would also only make corrupt files. Perhaps if I examine the files, or make some test payloads, I may be able to determine what's going on, but that will need to wait for another day. I know that Ian made some changes the software, either to the frehd, trs-80 or both, to make the frehd work on a Model 1, but as of now I am not sure what those changes are.

It may be better to continue my ATMEGA/dual port ram solution anyway, as this has the advantage of modifying any memory location.

===Version 7 of software - June 19, 2019===
It seems like there is some kind of problem with the 32K ram on the board, most likely a bad connection or something, which is near impossible to find. I sometimes find that reseating the SRAM chip or swapping it for a diffrent one will usually work, even though all of my ram chips test good using my EPROM programmer as a tester.

Anyways, I decided I needed to add a RAM test feature to the atmega operator interface. Before this, I created two 48k files of all 1s (0xFF) and all 0s (0x00), which I would load each with the '''rl''' command, which verifies each byte as it is written, allowing me to find RAM errors. Since this is a rather long command to type out, I decided to include a command <code>tstram</code> that would write all 1s, then all 0s, for each ram address over the entire 48K ram. An optional number after the command will specify the number of loops to do, from once to a whole bunch.

Additionally, I discovered a bug that would not allow the 3rd noun to be counted, making all commands think that there were only 2 nouns maximum (nouns=parameters after the command), making commands like <code>rd</code> inoperable. As a workaround for v7, I increased the allowed number of nouns to 4, which means that we still have the same error, but now the parser thinks that we can't have more than 3 nouns, which is the most that any command has. I will fix this properly in the next releases.

===v9 - Aug 2019===
Since the last log entry, I have indeed found the cause of the RAM issue - an address pin (one of the high address pins that isn't used) was left floating! This means that the ram would randomly switch to a different bank; this would be as if the ram randomly erases everything sometimes.

The reason I discovered this was because I wired these extra address pins to some atmega pins, for an experiment. Now, through the Atmega, I can switch the 32k of system ram between 4 banks.

I also am experimenting with an on-board terminal for the Atmega terminal control interface. From the little z80 program running in the dual port RAM, we already have access to the TRS-80 keyboard. To get access to the screen, we can call address 0x033a, which writes the character in A onto the screen, then advances the cursor. There are a few other routines <ref>http://www.trs-80.org/trs-80-rom-routines-documented/</ref> that can help manage the screen, so that makes things like advancing the cursor and scrolling down something that I don't need to implement myself in my own program. I added calls to these routines in SHRIP, meaning that SHRIP-ACPT can now write stuff directly to the screen. I even added extra functions to the ACPT sketch, to make the Arduino stream functions like Serial.print also write to the TRS-80 screen.

Ok, so we now have access to the TRS-80 screen and keyboard. The last step is to make ACPT available on the TRS-80 directly, without needing to use an extra serial terminal on the Atmega. I added a keyboard shortcut to SHRIP, which will enter into an on-screen ACP terminal. All I need to do is first copy the contents of the screen and save the cursor position so I can get back exactly where I left off. I store the image data in one of the extra banks of SRAM, since it is literally wasted space until now. When I'm done with the terminal, I issue the exit command, and the screen data is copied back onto the screen.

This means it is now possible to load machine code directly from the Atmega SD card into trs-80 memory, and execute it, without ever hooking up the trsei2 board to another computer. You can't really load full ram images yet, because the onscreen terminal itself uses some of the system RAM, but overall, the system is much more accessible now.

===v12 - December 2019===
With 128K of SRAM on the expansion board, it would really be nice if that extra ram could be accessed from the Z80 side of things, so that I don't have to go through the Atmega. This should also speed up assembly programs that use the extra RAM.
In the memory mapped IO section that breaks out address 37E0-37EC, I used 74LS138 octal decoders, so I also have lines for 37F0-37FC that are not used in a standard TRS-80. Therefore, I connected a 74LS175 latch to data pins D0-D1, and latch on writes to memory address 37FC. This makes the extra RAM (4 blocks of 32K, placed in the upper half of Z80 memory map) accessible from the Z80 directly.

Hardware also has a parallel port added, which is nothing more than a couple buffers and latches. I needed this to make the winter camp latrine monitor program, since I discovered that it needs a printer to work properly.

===RS-232 board - 3-24-2020===
The real expansion interfaces had an option for a RS-232 serial port, which enabled communication to the outside world; most modems required an RS232 port. Since I want to hook this up to a raspberry pi eventually, I'll need one.

The original board used a tr1602 UART and BR1941 as the baud rate generator. I couldn't find either of these chips to, but I did find a TR1865 and COM8136, which are chips used in the Model 4, and are compatible. They also do not require a -5 or 12V supply, not that it's a big deal as I have an ATX supply as the power source. There's also a few supporting 74 series components, and some buffers to convert the 5V signals to the RS-232 voltages. In place of the buffers, I will try to use MAX232s instead, since I have a bunch of them for some reason.

For address decoding, I am trying a GAL22v10. Normally I don't like using GAL programmable logic, because these chips are no longer made (there's still a lot though), and they sort of obscure how everything works. In this case, I found myself short of 74 logic chips in the middle of a global pandemic, so why not try something else and replace 4-5 74 chips instead.

==References==
<references />

Coronameter

2020-03-15T02:17:42Z

Alnwlsn:

As Michigan gets it's first cases of COVID-19 and events, schools, and businesses close up, this global pandemic starts to feel a lot more real. To stay properly panicked, I decided to re-purpose my old temperature display from college as a dedicated screen showing what the score is.

CDC and WHO update slowly, so for country and world stats I used a mirror of the John Hopkins interactive map you might have seen around, but in an easier to work with JSON format. For State data, I use the michigan.gov site, which I found to update more quickly.
I also decided to include the Dow and S&P indexes, as well as Clorox, just for the meme. That data comes directly from Yahoo Finance (not the discontinued API, but scraped off their website).

==Screen==
===Hardware===
The hardware is nothing more than a ST7920 LCD wired to an ESP8266. The screen runs at 5V, so there is a logic level converter thrown in, too. This screen used to be a display for my indoor outdoor temperature thingy, is crudely soldered, and had no case. First order of business was to design and 3D print a small plastic enclosure for it. After wiring up a 5V wall adapter, the hardware is done.
===Software===
When it was a temperature display, all the fetching of data was done on the ESP8266 itself. For the new system, I decided to just make the display dump the contents of raw UDP packets. That way, I can do the hard work in an external program (like Python) and send it over to the screen when done. I did the same thing with the Winter Camp Mission timer setup with [[Nixie Clock 2|the Nixie Clocks]], and a character VFD hooked to an 8266, and it worked very well.

The screen is driven using u8g2lib, and since the ST7920 doesn't have a built in text mode with this library, it was up to me to pick out a font and position the characters on the screen. U8g2lib will draw the characters graphically. I wound up with 21 columns and 7 rows, 147 characters total. On a screen this size, this makes for large and clearly readable text, even at a distance.

<pre>#include <Arduino.h>
#include <U8g2lib.h>

#include <ESP8266WiFi.h>
#include <WiFiUdp.h>
#include <ESP8266mDNS.h>
#include <ArduinoOTA.h>

const char* ssid = "ssidname"; // your network SSID (name)
const char* pass = "password"; // your network password

unsigned int localPort = 4212;
WiFiUDP Udp;

U8G2_ST7920_128X64_F_SW_SPI u8g2(U8G2_R0, /* clock=*/ 12, /* data=*/ 13, /* CS=*/ 4, /* reset=*/ 14);

char zbuffer[32];

char sbuf[148];

unsigned int millistimer=0;

void setup(void) {
u8g2.begin();
Serial.begin(74880);

u8g2.setFont(u8g2_font_profont11_tr);
u8g2.setFontRefHeightExtendedText();
u8g2.setDrawColor(1);
u8g2.setFontPosTop();
u8g2.setFontDirection(0);

sprintf(zbuffer, "Starting");
u8g2.drawStr(0, 0, zbuffer);
u8g2.sendBuffer();

WiFi.mode(WIFI_STA);
WiFi.softAPdisconnect (true);
WiFi.begin(ssid, pass);

while(WiFi.status() != WL_CONNECTED){
delay(1000);
}

Serial.println(WiFi.localIP());
u8g2.clearBuffer();
sprintf(zbuffer, "OK: %d.%d.%d.%d",WiFi.localIP()[0],WiFi.localIP()[1],WiFi.localIP()[2],WiFi.localIP()[3]);
u8g2.drawStr(0, 0, zbuffer);
u8g2.sendBuffer();

Udp.begin(localPort);
ArduinoOTA.setHostname("graphomatic-udp");
ArduinoOTA.begin();

millistimer=millis();
}

void loop(void) {
ArduinoOTA.handle();
int packetSize = Udp.parsePacket();
if(packetSize){
Udp.read(sbuf, sizeof(sbuf));
u8g2.clearBuffer();
u8g2.setFont(u8g2_font_profont11_tr);
u8g2.setFontRefHeightExtendedText();
u8g2.setDrawColor(1);
u8g2.setFontPosTop();
u8g2.setFontDirection(0);
byte x=0;
byte y=0;
byte c=0;
while(sbuf[c]!=0&&c!=255){
if(sbuf[c]>31&&sbuf[c]<127){
u8g2.drawGlyph(x*6+1,y*9-1,sbuf[c]);
}
if(sbuf[c]==10){y++; x=255;}
x++;
if(x==21){x=0; y++;}
c++;
}
u8g2.sendBuffer();
}

}</pre>

==Getting the data==
Next, I need to get the stats, format it for the screen, and send it over. Python makes this easy to do, even though I hadn't done this before.

Some of the numbers I get using a regex on the raw html I get when doing a request to a webpage. Another site I pick from that shows the COVID-19 world and country stats gives a JSON response, which Python also has good tools to work with.

<pre>import requests
import json
import re
import socket
import datetime
import time

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

while 1:
try:
rW = requests.get('https://covid19.mathdro.id/api')
wc = rW.json().get('confirmed').get('value')
wd = rW.json().get('deaths').get('value')
wr = rW.json().get('recovered').get('value')
except:
wc=0
wd=0
wr=0

try:
rA = requests.get('https://covid19.mathdro.id/api/countries/USA')
ac = rA.json().get('confirmed').get('value')
ad = rA.json().get('deaths').get('value')
ar = rA.json().get('recovered').get('value')
except:
ac=0
ad=0
ar=0

try:
rM = requests.get('https://covid19.mathdro.id/api/countries/USA/confirmed')
rMj = [x for x in rM.json() if x.get("provinceState") == "Michigan"][0]
#mc = rMj.get('confirmed')
md = rMj.get('deaths')
mr = rMj.get('recovered')
except:
md=0
mr=0

try:
rD = requests.get('https://www.michigan.gov/Coronavirus')
mc = int(re.search("Positive for 2019-nCoV(.*?)  (.*?)<", rD.text, re.DOTALL).group(2))
except:
mc=0

try:
rD = requests.get('https://finance.yahoo.com/quote/%5EDJI?p=%5EDJI')
dow = float(re.search("D\(b\)\" data-reactid=\"14\">(.*?)<", rD.text).group(1).replace(",",""))
except:
dow=0

try:
rD = requests.get('https://finance.yahoo.com/quote/%5EGSPC?p=%5EGSPC')
sp = float(re.search("D\(b\)\" data-reactid=\"14\">(.*?)<", rD.text).group(1).replace(",",""))
except:
sp = 0

try:
rD = requests.get('https://finance.yahoo.com/quote/CLX?p=CLX')
clx = float(re.search("D\(b\)\" data-reactid=\"14\">(.*?)<", rD.text).group(1).replace(",",""))
except:
clx=0

buf = "Wilson's Coronameter "
buf += ("W %d|%d|%d" % (wc, wd, wr)).ljust(21)
buf += ("USA %d|%d|%d" % (ac, ad, ar)).ljust(21)
buf += ("MI %d|%d|%d" % (mc, md, mr)).ljust(21)
buf += ("DJ %.1f S&P %.1f" % (dow, sp)).ljust(21)
buf += ("CLX %.1f" % (clx)).ljust(21)
buf += (datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")).ljust(21)

sock.sendto(buf.encode(), ('192.168.1.44',4212))
print(buf)

j = datetime.datetime.now().strftime("%M")
while j == datetime.datetime.now().strftime("%M"):
time.sleep(1)
</pre>

Coronameter

2020-03-15T02:05:27Z

Alnwlsn:

As Michigan gets it's first cases of COVID-19 and events, schools, and businesses close up, this global pandemic starts to feel a lot more real. To stay properly panicked, I decided to re-purpose my old temperature display from college as a dedicated screen showing what the score is.

==Screen==
===Hardware===
The hardware is nothing more than a ST7920 LCD wired to an ESP8266. The screen runs at 5V, so there is a logic level converter thrown in, too. This screen used to be a display for my indoor outdoor temperature thingy, is crudely soldered, and had no case. First order of business was to design and 3D print a small plastic enclosure for it. After wiring up a 5V wall adapter, the hardware is done.
===Software===
When it was a temperature display, all the fetching of data was done on the ESP8266 itself. For the new system, I decided to just make the display dump the contents of raw UDP packets. That way, I can do the hard work in an external program (like Python) and send it over to the screen when done. I did the same thing with the Winter Camp Mission timer setup with [[Nixie Clock 2|the Nixie Clocks]], and a character VFD hooked to an 8266, and it worked very well.

The screen is driven using u8g2lib, and since the ST7920 doesn't have a built in text mode with this library, it was up to me to pick out a font and position the characters on the screen. U8g2lib will draw the characters graphically. I wound up with 21 columns and 7 rows, 147 characters total. On a screen this size, this makes for large and clearly readable text, even at a distance.

<pre>#include <Arduino.h>
#include <U8g2lib.h>

#include <ESP8266WiFi.h>
#include <WiFiUdp.h>
#include <ESP8266mDNS.h>
#include <ArduinoOTA.h>

const char* ssid = "ssidname"; // your network SSID (name)
const char* pass = "password"; // your network password

unsigned int localPort = 4212;
WiFiUDP Udp;

U8G2_ST7920_128X64_F_SW_SPI u8g2(U8G2_R0, /* clock=*/ 12, /* data=*/ 13, /* CS=*/ 4, /* reset=*/ 14);

char zbuffer[32];

char sbuf[148];

unsigned int millistimer=0;

void setup(void) {
u8g2.begin();
Serial.begin(74880);

u8g2.setFont(u8g2_font_profont11_tr);
u8g2.setFontRefHeightExtendedText();
u8g2.setDrawColor(1);
u8g2.setFontPosTop();
u8g2.setFontDirection(0);

sprintf(zbuffer, "Starting");
u8g2.drawStr(0, 0, zbuffer);
u8g2.sendBuffer();

WiFi.mode(WIFI_STA);
WiFi.softAPdisconnect (true);
WiFi.begin(ssid, pass);

while(WiFi.status() != WL_CONNECTED){
delay(1000);
}

Serial.println(WiFi.localIP());
u8g2.clearBuffer();
sprintf(zbuffer, "OK: %d.%d.%d.%d",WiFi.localIP()[0],WiFi.localIP()[1],WiFi.localIP()[2],WiFi.localIP()[3]);
u8g2.drawStr(0, 0, zbuffer);
u8g2.sendBuffer();

Udp.begin(localPort);
ArduinoOTA.setHostname("graphomatic-udp");
ArduinoOTA.begin();

millistimer=millis();
}

void loop(void) {
ArduinoOTA.handle();
int packetSize = Udp.parsePacket();
if(packetSize){
Udp.read(sbuf, sizeof(sbuf));
u8g2.clearBuffer();
u8g2.setFont(u8g2_font_profont11_tr);
u8g2.setFontRefHeightExtendedText();
u8g2.setDrawColor(1);
u8g2.setFontPosTop();
u8g2.setFontDirection(0);
byte x=0;
byte y=0;
byte c=0;
while(sbuf[c]!=0&&c!=255){
if(sbuf[c]>31&&sbuf[c]<127){
u8g2.drawGlyph(x*6+1,y*9-1,sbuf[c]);
}
if(sbuf[c]==10){y++; x=255;}
x++;
if(x==21){x=0; y++;}
c++;
}
u8g2.sendBuffer();
}

}</pre>

==Getting the data==
Next, I need to get the stats, format it for the screen, and send it over. Python makes this easy to do, even though I hadn't done this before.

Some of the numbers I get using a regex on the raw html I get when doing a request to a webpage. Another site I pick from that shows the COVID-19 world and country stats gives a JSON response, which Python also has good tools to work with.

<pre>import requests
import json
import re
import socket
import datetime
import time

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

while 1:
try:
rW = requests.get('https://covid19.mathdro.id/api')
wc = rW.json().get('confirmed').get('value')
wd = rW.json().get('deaths').get('value')
wr = rW.json().get('recovered').get('value')
except:
wc=0
wd=0
wr=0

try:
rA = requests.get('https://covid19.mathdro.id/api/countries/USA')
ac = rA.json().get('confirmed').get('value')
ad = rA.json().get('deaths').get('value')
ar = rA.json().get('recovered').get('value')
except:
ac=0
ad=0
ar=0

try:
rM = requests.get('https://covid19.mathdro.id/api/countries/USA/confirmed')
rMj = [x for x in rM.json() if x.get("provinceState") == "Michigan"][0]
#mc = rMj.get('confirmed')
md = rMj.get('deaths')
mr = rMj.get('recovered')
except:
md=0
mr=0

try:
rD = requests.get('https://www.michigan.gov/Coronavirus')
mc = int(re.search("Positive for 2019-nCoV(.*?)  (.*?)<", rD.text, re.DOTALL).group(2))
except:
mc=0

try:
rD = requests.get('https://finance.yahoo.com/quote/%5EDJI?p=%5EDJI')
dow = float(re.search("D\(b\)\" data-reactid=\"14\">(.*?)<", rD.text).group(1).replace(",",""))
except:
dow=0

try:
rD = requests.get('https://finance.yahoo.com/quote/%5EGSPC?p=%5EGSPC')
sp = float(re.search("D\(b\)\" data-reactid=\"14\">(.*?)<", rD.text).group(1).replace(",",""))
except:
sp = 0

try:
rD = requests.get('https://finance.yahoo.com/quote/CLX?p=CLX')
clx = float(re.search("D\(b\)\" data-reactid=\"14\">(.*?)<", rD.text).group(1).replace(",",""))
except:
clx=0

buf = "Wilson's Coronameter "
buf += ("W %d|%d|%d" % (wc, wd, wr)).ljust(21)
buf += ("USA %d|%d|%d" % (ac, ad, ar)).ljust(21)
buf += ("MI %d|%d|%d" % (mc, md, mr)).ljust(21)
buf += ("DJ %.1f S&P %.1f" % (dow, sp)).ljust(21)
buf += ("CLX %.1f" % (clx)).ljust(21)
buf += (datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")).ljust(21)

sock.sendto(buf.encode(), ('192.168.1.44',4212))
print(buf)

j = datetime.datetime.now().strftime("%M")
while j == datetime.datetime.now().strftime("%M"):
time.sleep(1)
</pre>