VIC-20 with IEEE-488

[carlsson]

Aye. We could probably fill a whole off-topic thread about delivery delays in domestic and international sendings. I'm reading the blog of a US woman now living in Sweden, and had set up for her adult daughter to come and visit her. First, the e-ticketing system broke down so the ticket seller printed tickets, and managed to send those to Sweden, although the passenger lives in the US. Unfortunately, UPS managed to deliver them before it was cancelled. So the woman tries to find a way to send them back to her daughter. She doesn't find a local UPS delivery service, so she sends the flight tickets as express mail via the post office.

More than a week later, noone has yet seen the flight tickets. The post office makes lame excuses that express mail can not be traced outside the country (despite claiming the opposite!) and frankly they don't know which post service or delivery company in the US they have a deal with to pick up express mail sent from Sweden?!?! Fortunately, the boyfriend of her daughter convinces the ticket seller to issue new e-tickets and scratch the booking number for the printed ones that are circulating somewhere, perhaps at the bottom of a big bag of mail somewhere in New York City.

[ral-clan]

Yesterday, hmm? In that case, mail from Canada to Sweden seems twice or thrice as fast as when sending in the other direction. Not sure why.

No, I got mine last week. Remember we chatted about it over PMs? It only took about four days to come from Sweden to Canada. Faster than Vancouver to Toronto!

[ruud]

To be continued......

For Anders: Of course I checked things with both VICs :)

I finished the disassembly of the ROM. And I don't know what to think of it. The fact is that there is quite some code that simply is not used. Have a look at this piece of code:

Code: Select all

		bcs	L_B0D6	; if > 3 then ->

		jmp	CkOutOrg	; 				$F321

L_B0D2	sta	DFLTO
		clc
		rts

L_B0D6	jmp	L_B0E8


; not used IMHO  ===>
L_B0D9	nop
		jmp	ByteOutIEC2	; 				$F332

L_B0DD	cmp	#$09
		bne	L_B0E8

		jsr	L_B59D	; 				$B59D
		sta	DFLTO
		clc
		rts
; not used IMHO  <===


L_B0E8	jsr	CkOut2	; 				$B40C

The first line is a branch to a JMP that jumps to a line that is in reach of the original branch. But it also looks that this JMP and the following NOP replace a sequence of " CMP ... , BNE ...". The routine L_B59D addresses the hardware that is suposed to be at $9C01, which makes no sense at all in this design.

My idea about the whole is that somebody hacked another cartridge using a monitor because he hadn't the sources. If he had, it would have cost him (or her) just a few minutes to get rid of the unused code.

In a very early stage the line CMP #$09 at $B0DD gave me the impression that the designer wanted to allow the use of both the IEEE and IEC drives and disabled it with this JMP/NOP construction. Still having about 410 free bytes, even about 700 if we dump the code marked as 'not used', it should be simple to implement this feature.
Using a configuration byte, we could have something like:
Bit 0 = (H): addressing device 8 means addressing device 8 at the IEEE bus, addressing device 16 means addressing device 8 at the IEC bus
Bit 0 = (L): the same as above but now the IEEE and IEC bus are swapped.
or
Bit 0 = (H): addressing device 8 means addressing device 8 at the IEEE bus, addressing device 9 means addressing device 9 at the IEC bus
Bit 0 = (L): the same as above but now the IEEE and IEC bus are swapped.
And we don't have to search for a free byte in the memory of the VIC-20, we can use the free port A of one of the 6522's for this purpose.

Another idea: using a port expander we can add a cartridge with a 6551 or 8250/16450/16550 RS232 IC. An other bit can tell the software to intercept all communication with device two and to diverse it to this new cartridge; no extra EPROM needed :)

Comment, ideas, etc. are welcome.