Skip to content

This Time It’s Serious 

 We have a string of sunny days forecast with no precipitation. It’s propped up in full sun at a 45 degree angle. If a week like this doesn’t do it, I call BS on the whole sunlight erasing UV chips thing.

I have a blank chip on its way and I do mean to order an eraser if I need one, but I would like to see this work.

I was a bit worried about the chip overheating but I measured it when it was in the plastic bag and it hit 109°F. The chips are rated for something like 85°C in the service and 150°C in storage.

Update: After a bit less than a week of steady sunny days the UV EPROM is clearly losing its programming. Large parts of the chip are cleared to 0s although there are still remnants of the code. The erasure pattern is certainly peculiar though. locations 00-07,10-17,20-27 etc are cleared to 0’s but 08-0F,18-1F etc still have quite a few bits set corresponding to the originally programmed code. Further down the chip huge swaths have been cleared to 0.

The common wisdom was that a couple of weeks of sun would do it and i’d say that’s fair. I would add that modern window glass protected the chip VERY well and even a sandwich bag inhibited erasure. The image on the left is the current state and the right is the state when i set it out to bake 6 days ago.


Summary – Overclocking the COSMAC CPU’s

The video above shows the membership card CPU board that powers the 1802 Olduino running at 8MHZ. The Membership Card normally runs at 1.8MHz but the CPU’s are rated for 5MHz and I had been running the olduino at 4MHz. I built a new CPU card which Lee Hart, the designer, thought would suit the higher speed. The 4093 chip used in the clock oscillator has been replaced with a higher spec 74HC132 and I left a socket for the resonator so I could try various speeds.

I had three CPU chips handy to test with, an RCA branded CDP1802ACE, a Harris branded CDP1806ACE, and an RCA branded CDP1805ACE. These are all 5V parts rated for 5MHz. The 1806 and 1805 have extra instructions and the 1805 has onboard memory but both are pin compatible with the 1802 except for lacking the hardware load mode.

Having loaded a blink program with the 1802 at 4MHz, I tried each chip with 4,6, and 8MHz resonators. The 1802 ran fine at 4 and 6MHz but failed at 8MHz although it seemed to be clocking ok and producing timing pulses. The 1806 worked at 4 and 6MHz but at 8MHz it stopped producing TPA and TPB. The 1805 ran fine at 4,6, 8, and even 10MHz. I think the difference is down to sample variation rather than CPU type or brand but I may source additional parts to try.

In the gallery below there’s a chunk of the membership card schematic showing the pin changes to accommodate the 74HC132 replacing the 4093, images of the top and bottom of the board showing cut traces and jumpers to make the pin changes, and an image of the bottom of the finished board with those changes plus my other changes that accommodate the narrow ROM at U8 and bring signals over to a secondary connector for the olduino card.

Well duh… Also YAY!

I started doggedly buzzing out all the connections and realized that without the front panel or the olduino adapter, the membership card circuitry has /mwrite disconnected so a super-simple program would work but the blink sketch wouldn’t.
The video above has it running the blink sketch with a 6MHz resonator in place. The orange jumper in the 30 pin connector is bridging /mwrite. It would not blink at 8MHz but I’ll leave that for another day.

Despite all the nonsense I’m a bit excited about running it naked like this. As soon as I get a bootloader in ROM I’ll make a little adapter to fit on the 30 pin connector with the power/serial header and a Q LED(oh, and a reset circuit). I’ll lose my SPI circuitry but it will be easier to get at the processor and memory while I work on the speed.

And still puzzled

I’m pretty sure it’s a mistake to try and debug a hardware problem by looking at the software but that’s what I’m doing. Trying to trace what goes wrong by looking at the bottom five address lines TPA and /mread. Of course, when I hook everything up it works!


I think the following is true:

  • The simplest loop (seq,req,br 0)will run with or without the olduino attached
  • A similar program with a filler in it will only run with the olduino attached
     lbr far:
     db dup 256(0)
far: req
     lbr 0

Feels like something to do with an address line but the olduino doesn’t attach to the address lines. This is at 4MHZ so there’s nothing i haven’t run before.
17-08-20 bottom 1
Ah – just noticed that the lead that should have been going to TPB on pin 33 of the 1802 was actually connected to one of the address lines on pin 28. TPB is an input to the olduino board so it doesn’t seem a big deal but…

And sadly, fixing that didn’t change the symptoms. More tomorrow.

First Mate is So So

I finished off soldering the CPU card and tried it with the olduino adapter.  Initially things looked great – a blink sketch loaded and blinked merrily away at 4MHZ. After that not so good. I tried replacing the resonator for 8MHZ. No blinky but when i put the 4MHZ crystal back in it blinked. Going back to the testbed(taking off the olduino card) I find Q stuck at 5V although the processor is cycling and address lines are flipping. Put back the olduino adapter and it blinks! I have no hypothesis about the cause.

In the gallery below you can see the bottom of the card with the secondary header added and soldered and the simple testbed.

WooHoo – The Screamer is Screaming!

17-08-19 8MHZ 47pfAs of end of day today all of the on-board soldering is done and the clock circuit delivers stable pulses up to (probably) 10 MHZ. The processor is generating timing pulses and state codes and generally looks good. I tried actually running a 7B 7A 30 00 sequence by loading in on a working olduino and transplanting the memory but it doesn’t seem to be pulsing Q. It is doing fetch/execute cycles though so i’m sure it’s something simple.

I say it probably works at 10MHZ because my logic analyzer shows varying pulse widths averaging 10MHZ – I think it’s just an issue of sampling at 24MHZ.

Update: when I actually hooked up the probe to Q I could see it pulsing just fine at 8MHZ!
17-08-20 Q

UV Eprom’s is Tough!

I got my EPROM programmer today so I pulled the CY27C256 in from it’s sunbathing and read it out. The program josh burned in is still there! The first part of the EPROM seems completely as-burned although there are blocks later on that do show some corruption. I had accepted that it was never going to erase protected by 2 layers of good window glass but I did think that a week outside in a ziplock would do the trick!
I’ll have to buy an eraser but in the meantime I’ll get Josh to mail me back the second sample I sent him and use that. I’m going to want this part on hand for building up the 1806 screamer for the next couple of days but I’ll eventually put it back out for another sun-soak unless the I order an eraser and it shows up quickly.

Building an 1806 Screamer III

There’s the top and bottom view with the passives mounted except those that go under the socket for the wide memory chip. I’m not proud of the soldering but my experience with these boards is that i need to make sure the holes are full of solder to be confident that it’s a good connection.

Building an 1806 Screamer II

There are the board changes I need to make to accommodate the 74HC132 replacing the 4093 and the CY27C256. The 74HC132 is needed for the higher clock speed and the changes are the same ones I made before. For the CY27C256 ROM It’s basically the same but I’m cutting the trace in what I think will be an easier spot and I’m not initially rewiring pin 1 (VPP) because the data sheet says it’s a “don’t care” unless it’s actually 12V.

Next Steps:

  1. make the trace cuts noted in red
  2. install the small components – resistors, jumpers,capacitors
  3. install the sockets
  4. cut the wide memory chip socket (U2) to allow the narrow(U8) chip to go in
  5.  install socket pins for the narrow chip and resonator
  6. install the 30 pin connector
  7. test all the +V and gnd points for correct voltages
  8. install the resonator and 74HC132 – see if it clocks at 4MHZ, 6MHZ and 8MHZ
  9. install the other ICs checking for smoke
  10. 10 see if the processor will execute code from the wide memory
  11. install the 8 pin connector
  12. try it with the olduino board at 4MHZ.


Building An 1806 Screamer

I’m building the latest version of the 1802 Membership Card with the intention of running it 8MHZ. Several folks on the list have been successfully running 1802s at 8MHZ with no special care and one guy pushed an 1802 to 35MHZ!

Additionally I’m planning from the beginning to run an 1806 CPU with a boot rom in addition to the usual non volatile SRAM. In the image above i’ve loose-fit most of the bits too see what I still have to order – basically a few sockets, a resistor SIP, and the 1 meg pot in addition to the resonators.

UV EPROM left in the sun DID NOT ERASE in Three Weeks!

Huh. My EPROM Programmer did not show up while I was away but I put the CY27C256 EPROM into the olduino to see if it had erased in the 20 days I was away. The contents seems to be untouched. So much for that technique!
17-08-10 uv-no-erase
With any luck I will only have to program this thing once or twice but it seems i may need to get an eraser. In the mean time I may but the EPROM outdoors in a plastic bag and see if that “takes”.

UV EPROM left in the sun to erase while I’m away.

I’ve read that it can take as little as a few days but this will be an n a south facing window for about three weeks before I check it. I’m hoping my programmer will arrive while I’m away too.

Xmodem Transfer With Timeout

The reason for playing with xmodem (and the narrow rom for that matter) is to develop a bootloader that runs over serial so i can get rid of the avr on the olduino board and have the 1802/1806 stand on its own.  A bootloader needs to check to see if there’s anything to load and, if not, jump to the program that’s already loaded in the non-volatile memory.  That amounts to doing a timeout on the serial line after sending the first NAK to start the xmodem sequence.

I have this working although I’m not happy with the code. It turned out to be easy enough to put a timeout into the serin routine.  It just counts R14 down from 0 til it wraps around as in the code below.  It started out as a 4 instruction loop so 65K*4*16 cycles or around 1 second at 4MHZ.  I stuck a couple more tests for the start bit in bringing it to 6 instructions or 1.5 sec at 4MHZ and reducing latency at the same time.  Once I actually start working with host sender i’ll fine tune it. If the start bit doesn’t show up before the time delay pops, serinT sets the DF flag and returns.

serinT:			;serial input with timeout of 65535*6*16 machine cycles - approx 1.5 sec at 4MHZ
	ld2Z R14	;R14 is timeout loop counter
.rxcw:	b3 .okgo	;check for start bit after each instruction
	dec 14
	b3 .okgo	;check for start bit after each instruction
	ghi 14
	b3 .okgo	;check for start bit after each instruction
	bnz .rxcw
;here we've had a timeout - set DF and return
	ldi 1
	sep R3		;return
	br  serinT	;for next time

The xmodem receiver is checking for the DF flag at the beginning of each block and, if it sees a timeout it 0’s the return address and quits.  In the C test mule this just reports the failure.  I’m not happy because: a) the code seems ugly and b) I don’t really want to time out part way through a bootload and jump to a half-loaded program.

	   ldi     NAK                 ; need to send NAK to start
           sep     Rsnd
filelp:    ;receive address is in R12, length goes in R11
;begining of block read. returns to filelp or exits to filedn(or quits for timeout)   				
           sep     Rrcv               ; wait for next incoming character
           bnf     .ckeot		;continue if no timeout
	   ldaD    R15,0		;set return value to 0
  	   ldi 'T'

.ckeot:    smi     EOT              ; check for EOT

Anyway, it works for now and maybe I’ll get smarter with the actual bootloader.
UPDATE: I was thinking this might be less ugly if I did the timeout test in the xmodem routine rather than in the serin code. I looked at it a bit though and it might work better but the code would actually be harder to understand.

#include <olduino.h>
#include <nstdlib.h>
#include <cpu1802spd4port7.h>
int XR(unsigned char *);
void dump(unsigned char* data, unsigned int len){
	unsigned int i=0;
	printf("dumping %d bytes at %x",len,data);
		if (0==(i%8)) printf("\n%x ",data);
		printf("%cx ",*data++);
void check(unsigned char* data, unsigned int len){
	unsigned int blk,i=0;
	unsigned char csum=0;
	printf("checking %d bytes at %x\n",len,data);
	for (blk=0;blk<len/128;blk++){
		for (i=0;i<128;i++){
		printf("block %d, checksum %cx\n",blk,csum);
void main(){
	int ret;
	asm(" seq\n"); //make sure Q is high to start
	delay(500); //long enough to notice
	printf("Calling XR\n",ret);
	ret=XR((unsigned char *)0x7000);
	printf("XR returns %x\n",ret);
	if (ret){
		dump((unsigned char *)0x7000,ret-0x7000);
		check((unsigned char *)0x7000,ret-0x7000);
	} else{
		printf("Timeout - no transfer\n");
void includeser(){
	asm(" include xrwjrT.asm");
#include <olduino.c>
#include <nstdlib.c>

*************************ASM file follows*************************
NAK:	EQU 0x15;'N'
SOH:	EQU 0x01;'S'
EOT:	EQU 0x04;'T'
ACK:	EQU 0x06;'K'
Rrcv:	EQU 8
Rsnd:	EQU 9
blksize:	EQU 128
trc:	MACRO
	dec 2
	str 2
	out 7
; XMODEM receiver based on xr.asm by Michael H Riley and serial routines by Josh Bensadon   
; See bottom of file for full acknowledgements and links.
; On entry R12 points to memory where received data will go
; On exit R15 has the last byte written
	align 64
_XR:	   ldaD	   Rsnd,serout
	   ldaD    Rrcv,serinT
	ldi '<'
	   ldi     NAK                 ; need to send NAK to start
           sep     Rsnd
filelp:    ;receive address is in R12, length goes in R11

;begining of block read. returns to filelp or exits to filedn   				
           sep     Rrcv               ; wait for next incoming character
           bnf     .ckeot		;continue if no timeout
	   ldaD    R15,0		;set return value to 0
  	   ldi 'T'

.ckeot:    smi     EOT              ; check for EOT
           lbz     filedn           ; jump if so

	   sep     Rrcv               ; read block number
           sep     Rrcv               ; read inverted block number

           ldi     blksize             ; 128 bytes to receive
           plo     r11

readlp:    sep     Rrcv               ; read data byte
           str     r12                  ; store into output buffer
           inc     r12                  ; point to next position
           dec     r11                  ; decrement block count
           glo     r11                  ; see if done
           bnz     readlp              ; loop back if not
;end of block read
           sep     Rrcv               ; read checksum byte

           ldi     ACK                  ; send an ACK
           sep     Rsnd
           lbr     filelp              ; loop back for more
           ldi     ACK                  ; acknowledge end of transmission
           sep     Rsnd
	   glo	   R12			;copy last address to return register
	   plo     R15
	   ghi     R12
	   phi     R15
	ldi '>'
           cretn	           	; and return to caller

; *******************************************************************
; *** This software is copyright 2005 by Michael H Riley          ***
; *** You have permission to use, modify, copy, and distribute    ***
; *** this software so long as this copyright notice is retained. ***
; *** This software may not be used in commercial applications    ***
; *** without express written permission from the author.         ***
; *******************************************************************
;bit-bang Serial routines adapted from Josh Bensadon's VELFbios-v3.1.asm
;Transmit Byte via Q connected to RS232 driver
;call via SCRT
;Byte to send in D
;Destroys r14
bitdelay: MACRO baudrate,cpuspeed,baseline,xreg
	rept ((cpuspeed/(baudrate*8)-baseline))/3
	rept (((cpuspeed/(baudrate*8)-baseline)#3))>=1
	sex xreg
	align 64
serout:			;entry from assembly with char in D
	phi R14		;save char in R14.1
	ldi 9		;9 bits to transmit (1 start + 8 data)
	plo r14
	ghi R14
	shl		;set start bit
	rshr		;DF=0

	bdf $+5		;10.5   jump to seq to send a 1 bit
	req		;11.5   send a 0 bit
	br $+5		;1      jump +5 to next shift
	seq		;11.5   send a 1 bit
	br $+2		;1      jump +2 to next shift (NOP for timing)
	rshr		;2      shift next bit to DF flag
	phi r14		;3      save D in r14.1
	DEC r14		;4      dec bit count
	glo r14		;5      get bit count
	bz .txcret	;6      if 0 then all 9 bits (start and data) sent
	ghi r14		;7      restore D
	bitdelay __BAUDRATE,LCC1802CPUSPEED,20,2,{EXPAND}
	br .txcloop	;9.5    loop back to send next bit
.txcret: ghi r14		;7
	bitdelay __BAUDRATE,LCC1802CPUSPEED,16,2
	seq		;11.5 stop bit
	bitdelay __BAUDRATE,LCC1802CPUSPEED,4,2
	sep R3		;return 
	br serout	;reset for next time
;Receive Byte via EF3 connected to RS232 receiver
;Receives 8 bits
;call via sep
;Returns with Byte received in D, DF is set if the start bit is never seen
;Destroys r14
	align 64
serinT:			;serial input with timeout of 65535*6*16 machine cycles - approx 1.5 sec at 4MHZ
	ld2Z R14	;R14 is timeout loop counter
.rxcw:	b3 .okgo	;check for start bit after each instruction
	dec 14
	b3 .okgo	;check for start bit after each instruction
	ghi 14
	b3 .okgo	;check for start bit after each instruction
	bnz .rxcw
;here we've had a timeout - set DF and return
	ldi 1
	sep R3		;return
	br  serinT	;for next time
 .okgo:			;here we know the start bit is present
 	ldi 8		;start bit +7 bits from loop, last bit on returning
	plo r14
	ldi 0
	NOP		;delay to center samples

	bitdelay __BAUDRATE,LCC1802CPUSPEED,20,2
	b3 $+6		;11.5 sample rx input bit
	ori 80h		;1
	br $+4		;2
	phi r14		;1
	phi r14		;2
	shr		;3
	phi r14		;4
	DEC r14		;5
	glo r14		;6
	bz .rxcret	;7
	ghi r14		;8
	br  .rxcloop	;9
.rxcret: ghi r14	;8
	ghi r14		;9
	bitdelay __BAUDRATE,LCC1802CPUSPEED,20,2
	b3 $+4		;11.5 sample last rx input bit
	ori 80h		; for a 1 bit
	adi 0		;clear the DF flag because no timeout
	sep R3		;return
	br  serinT	;for next time
	ldad Rsnd,serout
	glo R12
	sep Rsnd
	ldad Rrcv,serinT
	sep Rrcv
	plo R15
	ldi 0
	phi R15
; *********************************************************************
; *** xmodem code based on xr.asm copyright 2005 by Michael H Riley ***
; *** You have permission to use, modify, copy, and distribute      ***
; *** this software so long as this copyright notice is retained.   ***
; *** This software may not be used in commercial applications      ***
; *** without express written permission from the author.           ***
; *********************************************************************
; The serial code is based on VELFbios-v3.1.asm by Josh Bensadon    ***

I always want the last word so that wordpress doesn’t eat my code!

Actually Fitting the Narrow ROM to the 1802 Membership Card

The membership Card CPU board is meant to take a narrow RAM directly soldered under the wide memory chip U2. I couldn’t solder in the CY27C256 ROM because it needs to come out for programming so I used solder pins which add a tiny bit to its already mighty height. With the ROM in place in the left hand image the pins of the RAM above it barely make contact with the socket. It actually does work but it would be vulnerable to shocks. As a short term measure I added a second socket over top which more than bridges the gap. The practical thing to do would be to use something like a wire-wrap socket(with long pins) for the wider memory at U2 and put a millimetre or so spacer under it to add clearance.

UPDATE: It looks to me like I can get away with using a fresh wire wrap socket without any spacer. It doesn’t actually lift the wide memory chip up that much but the new socket is that much tighter that it can give very good contact without the chip being absolutely fully seated. If I see something good to use as a spacer I may still do that but my experiments and googling so far have not been helpful.

The 1K Pullup (sounds like an exercise challenge doesn’t it)

At the suggestion of the designer (Lee Hart) I added a 1K pullup resistor to the /A15 circuit on the Membership card.  That tightened up the timing dramatically.  The A15 and /A15 which enable the RAM and ROM respectively are now just about identical at 2 uS.

17-07-03 yayThe dumper program works and i can move on to de-scrambling the address lines.

Well Heck – The Way Out of Bizarro World

17-07-01 bizarroFor several days I’ve been batting my head against a really odd problem with the Olduino.  With a ROM mounted and addressed at 0x8000 it seemed like I could not pass a pointer to the ROM to a subroutine even if I never referenced the address pointed to. I could accept that there was some problem where accessing the ROM would screw up but I couldn’t figure out where the access was happening.

It turns out the answer is in two parts:

17-06-30 A15First, the memory enabling circuit in the REV G membership card is just way too slow for my system.  It’s a single transistor that inverts A15. At 4 mhz the A15 signal goes high for 2 uS but the inverted signal goes low for almost 8 uS! Both memories are on the bus for several instruction times and hilarity ensues. This is a well known problem but not one i had noticed until it bit me.

17-07-01 mpm201Second, the d*mned 1802 systematically outputs the contents of a register on the address bus whenever you access it! In the table above it shows that the instructions that access the registers (GLO, PLO etc) drive the address bus with the register contents. After 40 years of working with the 1802 I DID NOT KNOW THIS! The 1802 does not assert /MRD or /MWR during these cycles so in theory no harm done but with the ROM enable being stretched, it was still active when the next instruction executed.

In later versions of the membership card schematic the enable circuit is changed a couple of times. If I don’t just give up on the ROM I may adapt one of the fixes or I might try to fit in an inverter.  Maybe one of the little logic single-gate chips in an SOT-23 package.

17-07-01 single gate

Adding A Narrow ROM To the 1802 Olduino – III

I’ve tried a couple of things accessing the ROM.  First, although I was warned, I forgot that the ROM address lines are scrambled to make the layout practical.  A0 goes to the ROM’s A4, A3 goes to the ROM’s A0, and A4 goes to the ROM’s A3.  Nothing I can’t fix in software but the ROM image I got Josh to burn is no good.

For determining power consumption I tried running the Olduino with the ROM in place but not accessed and then with various duty cycles. With no ROM access the Olduino is using about 60ma.  With the heaviest duty cycle I could manage it’s about 170ma(!).  So my plan to use it as a boot device is fine but you probably wouldn’t put your monitor in it.

It’s possible that there is something else going on because i am fighting some kind of issue that might be memory-related.  If I run the program below the output from the dump() routine is fine for addresses below 0x8000 but it’s corrupt for the addresses in the ROM.  If I move the dump code into main() it works fine. I can only think of some kind of memory overlap but I don’t know what. The ROM contents as printed is “correct” and the dump showing address 003F does in fact report what’s at 3F so this may not really be mysterious – just some sort of finger problem.

UPDATE: I dinked around with this for hours with no satisfactory result. Certainly the problem goes away if i remove the rom but i’m not sure if it’s the RAM not making good contact or some more straightforward electrical issue.

 #include <olduino.h>
#include <nstdlib.h>
#include <cpu1802spd4port7.h>
void dump(unsigned char* data, unsigned int len){
	unsigned int i=0;
	printf("dumping %d bytes at %x",len,data);
		if (0==(i%8)) printf("\n%x ",data);
		printf("%cx ",*data++);
void main(){
	unsigned char*ptr=(unsigned char *)32768;
	unsigned int i=0;
	printf("dumper here 3\n");
		if (0==(i%8)) printf("\n%x ",ptr);
		printf("%cx ",*ptr++);
	printf("\ndone inline dump\n");
	dump((unsigned char *)0x8000,64);

#include <olduino.c>
#include <nstdlib.c>
16:35:30.322> run1802.7.1(2000) for Hardware Loader
16:35:30.322> dumper here 3
16:35:30.432> 8000 37 30 F8 C0 AE 00 80 7A
16:35:30.432> 8008 12 09 00 80 F8 7B BE 30
16:35:30.432> 8010 EE 15 09 30 C4 80 37 FF
16:35:30.615> 8018 3F D8 6E 19 67 00 0E FF
16:35:30.615> 8020 FF FF FF FF FF FF FF FF
16:35:30.615> 8028 FF FF FF FF FF FF FF FF
16:35:30.615> 8030 FF FF FF FF FF FF FF FF
16:35:30.615> 8038 FF FF FF FF FF FF FF FF
16:35:30.615> done inline dump
16:35:30.615> dumping 64 bytes at 003F
16:35:30.922> 003F A1 B1 C0 00 75 81 FA 07
16:35:30.922> 0047 AB 91 FA 00 BB 8B CA 00
16:35:30.922> 004F 61 9B CA 00 61 F8 A4 AC
16:35:30.922> 0057 F8 0E BC 87 AD 97 BD D4
16:35:30.922> 005F 09 CB F8 9F AC F8 0E BC
16:35:30.922> 0067 87 AB 97 BB 17 0B AD F8
16:35:30.922> 006F 00 BD D4 09 CB 11 22 86
16:35:30.922> 0077 52 81 F7 96 52 91 77 12
16:35:30.922> done

UPDATE: I dinked around with this for hours with no satisfactory result. Certainly the problem goes away if i remove the rom but i’m not sure if it’s the RAM not making good contact or some more straightforward electrical issue.

UPDATE: I did a memory test of the RAM with the ROM in circuit and it looked fine. I made a simpler program that exhibits the fault:

#include <nstdlib.h>
#include <cpu1802spd4port7.h>
void dump(unsigned char* data){
    unsigned int i=0;
    printf(" %x",data);
void main(){
	printf("dumper here 6\n");
	dump((unsigned char *)0x8fff);
#include <nstdlib.c>
********************partial assembly text follows ****************
_dump:		;framesize=8
	reserve 6
	st2 R12,'O',sp,(8); flag1 
;void dump(unsigned char* data){
;    unsigned int i=0;
	ld2z R11
	st2 R11,'O',sp,(4); ASGNU2(addr,reg)
;    printf(" %x",data);
	ldaD R12,L2; reg:acon
	ld2 R13,'O',sp,(8) ;reg:INDIRP2(addr)
	Ccall _printf
	release 6

_main: ;copt is peeping your size 6 frame with oct 23 rules
	reserve 4
;void main(){
;	printf("dumper here 6\n");
	ldaD R12,L4; reg:acon
	Ccall _printf
;	dump((unsigned char *)0x8fff);
 	ldaD R12,0x8fff; reg:acon
	Ccall _dump

********************output follows ********************
15:32:08.807> run1802.7.1(2000) for Hardware Loader
15:32:08.807> dumper here 6

The address is passed to dump() in R12 and what is received is, in fact, the value that’s loaded into R12 by the printf() preceding the dump() call. Looking at the assembly code i just have no idea how this is happening!

Adding A Narrow ROM To the 1802 Olduino – II

Electrically this was not too bad.  I had actually picked a bad spot to cut the A14 trace but no big deal. The ROM’s A14 on pin 27 is jumpered to the RAM’s pin 1 and the ROM’s VPP on pin 1 is jumpered to VCC on its own pin 28.


Mechanically it is quite a bit trickier. I am using these little tiny pin sockets so I can remove the ROM for programming.  Even so, it barely fits under the RAM although there’s lots of room above it.  Getting the rom and sockets in place to solder was very finicky.  You normally put the pins on the IC then insert in the board and solder but these ROM chips have been through the wars and getting everything aligned was brutal.  I ended up starting with just a couple of pins at each end and inserting the chip from the back of the board where I had better access. Then I’d remove it and try it in the correct orientation.  Gradually, with a lot of fiddling I added pins, went front and back, and eventually everything lined up.

17-06-21 plenty of roomThe final mechanical issue is that there isn’t really room under the RAM for the bulky ROM chip. The RAM is just barely in its socket and it wouldn’t be reliable. I’ll have to either replace the RAM socket with something higher or use another layer of the socket pins.

Adding A Narrow ROM To the 1802 Olduino

The 1802 Olduino is based on the 1802 Membership Card by Lee Hart.  The board is quite full so in order to allow both ROM and RAM, Lee put a footprint for a .3″ wide memory chip under the .6″ wide footprint I use for non-volatile memory. I like the idea of adding a ROM so I can eventually get rid of the AVR on the olduino board and have the 1802 bootloader in ROM.  I have in mind to do a bit-bang serial xmodem loader but as a trial I’m going to burn the “fakeloader” into an EPROM so its gone off to Josh Bensadon who has a programmer that can handle the chip.

Because my NVRAM is .6″ wide, I have to put the ROM in the narrow socket.  Herb Johnson on the COSMAC mailing list was nice enough to let me have a couple of Cypress CY27C256s.  These are UV erasable EPROM so the pin layout is slightly different than the RAM that Lee was thinking of when he laid it out.  PIN 1 needs to go to 5V instead of A14, and pin 27 needs to go to A14 instead of /Write-Enable.

Boggling over the datasheets, the schematic, the actual board, and a copy of the board layout gerber files from Lee I’ve concluded that I can clip the traces leading to those pins under the board without hurting anything else and then jumper pin 1 of the inner chip across to its pin 28 and pin 27 over to pin 1 of the outside chip.  I’ve cut the traces and verified that the board still works but i’m waiting til I get the chip back from josh to do the jumpers. In the images below the segment of the board with the red Xs for the cuts is reversed from the gerber and the actual board because i found it easier to work with the top and bottom copper images if I was looking at both from the top.