Hi Geoff and ALL

All success to your new project. A USB would really bring the Einstein into the
modern world. It does though raise issues which are similar to my own
development of linking the Einstein user port and PC printer Port.

Interfacing a new device to the Einstein whether a PC, CF or USB for exchanging
memory is one thing but to intergrate it with DOS and making it compatible with
MOS is another. Additional code in the Einstein for interfacing the device would
have to be placed in the Einstein's RAM where exiting applications loaded in and
run will not over write it. It all starts to get more complicated.

So some questions to satisfy my curiosity.

>USB seems far more logical as, once implimented, it will support any USB Mass
Storage device. Most digital cameras currently use the same storage system so it
should be with us for a while.

USB certainly seems a more versatile option.

>adding onboard support for FAT file systems

I take it that this means the FAT file systems will need to be loaded into the
Einstein RAM at some location.
1: If this is so it will have to stay there when running other Einstein programs
in the TPA.
2: So where to put it and how big will it be?
3: Can it be placed without reducing the size of the TPA for other programing?
4: With a smaller piece of code could a piece of Einstein RAM be exchanged with
memory in a storage device run and be swopped back? Act something like a MOS
Mcal but from the storage device?

The CF Interface
I'm sorry you have brought closure to the compact flash interface. My regret is
that I didn't have the steadiness of hand and eyesight to solder up the finley
pitched pins of the compact flash holder. If I find a more manageable way to do
it I still will.

As I understand it from the documentation you have already provided there was
hardware and software instructions to read and write sector by sector to and
from the Einstein. I would be content and enjoy experimenting with this feature
alone. Find answers to my question 4.

Since providing your original documentation has there been any further
development hardware and/or software you can share with the group?
With hardware has full address decoding with the CF since been established?
Is there any new programing you have developed for accessing the CF you can
share with us?

My Own Development
As mentioned in a previous post I have established an Einstein user port / PC
printer port link for exchanging data. Example programing can be found at
http://www.einstein.talktalk.net/pio.html . A pdf document viewed or downloaded
from http://www.einstein.talktalk.net/download/pio_extra.pdf

From this I have further programing developed which will snapshot the whole of
Einstein RAM to a binary file on the PC. The MOS monitor command can be used to
type in a 194 bytes of code which will download a snapshot RAM file from the PC,
DOS as well, into the Einstein. So it is a way to boot Einey with a DOS without
a floppy disk drive and boot floppy.

I do not of course type in MOS the hex every time. I have saved it to a track
and sector of a formatted disc with the MOS Write command. The track and sector
and address to load to are written on the floppy. I start up the Einstein with
out a disk inserted and go into MOS. Insert the disk and load the code using MOS
READ. Then I remove the floppy. This is so I know the DOS I am using is always
that which has been downloaded from the user port and not been reloaded from a
disc.

The snapshot Einstein RAM files saved on the PC are useful for opening and
exploring the workings of the Einstein RAM with Windows HEX editors and Z80
disassemblers.

The snap shot RAM files can be altered in the PC. One innovation I've tried is
using BBCBASIC for Windows programing to insert an Einstein *.COM file into the
snapshot RAM before downloading into the Einstein. I've done this successfully
with XBAS basic and BBCBASIC, and as with other applications, had them running.
But! Where do I insert an *.XBS file? With BBCBASIC I know from documentation a
*.BBC file is inserted at &400.

The real answer I want is to alter or create a DOS which will point to the user
port to receive files and to be located in RAM where needed. For *.COM files
this is known to be the beginning of the TPA at &100 but when an application
wants to load its own file where is the destination address kept?

I know from documentation and from viewing the RAM snap shot files that the name
of a file to be downloaded by an application is placed at &5C. I also know the
2kb buffer for reading and writing bytes to and from disc is at &FE00. But!
Where is the address held to where the application wants these bytes transferred
to? Is there a &FB?? scratch pad location that gives this address listed in a
way that it doesn't describe its real purpose.

I've been trying to find this answer for months now and it is holding up my
progress. It has really shown up my ignorance of the workings of the Einstein
MOS and DOS.

Can anyone point me in the right direction.

Mcals and ROM switch-A Question?
To show my ignorance. When switched into ROM usually an "OUT (&24)" instruction
is the code in the ROM run by the processor or is it loaded into RAM to run?

I've been following through MCAL RST 8 insruction and the code it jumps to in
RAM at &FC22. The code for RAM is easy to follow then at &FC3B the ROM switch
OUT (24H),A - CALL L0FD7-OUT (24H),A. The CALL L0FD7 routine in MOS is then
quite happy to load &FB-- scratch pad values that are in RAM into registers such
as LD HL,(0FB3AH). How can it access RAM addresses if it is in ROM. IF it can do
this why doesn't the CALL L0FD7 in ROM goto &FD7 in RAM? !Totally confused.

For my own interest do any members have and use BBCBASIC for Windows?

All the best to all with there Einey projects.

Regards Chris Coxall


--- In tatung_einstein@..., "id_fugu_is_unavailable" <geoff@...>
wrote:
>
> Hi,
>
> Well, I've gathered some bits that should enable me to add a USB host port to
the Einsten.
>
> The chips and firmware I'm using have built in support for the FAT 12, 16 and
32 file systems (with the standard 8.3 naming convention) and should be able to
support a limited number of printers too.
>
> The CompactFlash project gave me a good insight into the hardware side of
things but the problem was always going to be that supporting IDE interfaces was
looking more like a dead end as IDE drives are being phased out in favour of
SATA, and adding onboard support for FAT file systems just for IDE looked like a
lot of effort for a small amount of supported hardware. USB seems far more
logical as, once implimented, it will support any USB Mass Storage device. Most
digital cameras currently use the same storage system so it should be with us
for a while.
>
> USB Flash Drives and Hard drives will all be accessable the same way,
regardless of how they are actually built.
>
> There's also the possibility of adding a number of USB HIDs (Human Interface
Devices) such as keyboards, touchpads and mice. I'm also looking into making a
network adaptor to get all these Einsteins online, firstly for email, then for
an Einstein BB style internet service, but that's some way off yet.
>
> I'll keep you all updated but posting this here will help me get my act
together.
>
> Regards,
> Geoff
>