With Ref: to phils post 290 message 290 From: "fil_simmons" *|I wonder if Chris could *|be prevailed upon (or more considerately, someone else might *|volunteer) to get a listing of all the posts and sort them *|chronologically under discussion threads. *|These could be posted as a *|zip and be downloadable from the files section.
Well if you have downloaded all_postings2.doc you know I'm working on it. In the text attachment is a program listing designed to be pasted into the BBCBASIC FOR WINDOWS free DEMO VERSION which will run in all versions of windows. The prog is a quickly hashed job just to get something up and running that I can use for myself at the moment. But you being Einey users most of you will have least have some hands on experience of writing basic. You might want to develop your own programs from the listing attached. Except for a couple of lines this is bbcbasic as you know of it in the Einstein. The program might even run in the Einstein but the PC is the target intention.
The program opens up all_postings2.doc and allows the user to select messages by post number and put just the selected into a new text file.
As Phil has said "it's really hard to keep track of topics and the 'state of play'". Browsing through all_postings2.doc I've noticed a lot message content on a subject that would be useful to give reference to the same subject in another message. There is a lot of message content including that of my own that gets lost from memory.
I'm working at an indexing method where similar subject material in different messages can be located by post numbers. A way that any group member who makes a new post can list message numbers where they know similar subject content is held.
The more help the better it will be to get messages sorted into some categorized way. Some original thinking is also needed here.
Regards Chris Coxall
SYS "ShowWindow", @hwnd%, 3 : REM. SW_MAXIMIZE
VDU 26
*|This basic program listing is designed to be
*|pasted into the BBCBASIC FOR WINDOWS free DEMO
*|VERSION to run in all versions of windows.
*|Download from http://www.rtrussell.co.uk/. Top two
*|lines set screen to full size they can be deleted.
*|The rest of the program is basic as that which
*|would run in the Einstein. This program is in a
*|temporary development stage to show the working
*|principle. Obvious improvements can be made. It is
*|being presented now so others can if they wish
*|develope thier own programming from it.
*|
*|The program will open the file "all_postings2.doc"
*|must be saved in same folder as "all_postings2.doc"
*|prompt for a message number -
*|display the text of the message on screen -
*|spool the selected message into a new text file "t.txt".
*|prompt for another message number
*|display message text on screen
*|and append message text to t.txt file.
*|The program is terminated by the "Q" or "q"
*|being pressed at the prompt for message number.
*|On closure the t.txt file will be opened in notepad
*|If text in t.txt is wanted it should be saved
*|to a new file name from notepad.
*|On running this program again the program will
*|delete old text in t.txt and replace it with new.
*|
file$="T.TXT"
INPUT"POSTING NUMBER ";A$
C$=" #"+A$+" "
x=OPENIN "all_postings2.doc"
PRINT" Please Wait Please Wait Please Wait Please Wait"
REPEAT
A$=LEFT$(GET$#x,LENC$)
UNTIL A$=C$ OR PTR#x=EXT#x
*SPOOL T.TXT
PRINTA$;
REPEAT
IF A$<>"" PRINT A$
A$=GET$#x
UNTIL LEFT$(A$,40)="Reply | Forward | Messages in this Topic" OR
PTR#x=EXT#x
PRINT
*SPOOL
IF PTR#x=EXT#x PRINT "NOT FOUND "
CLOSE#x
y$=""
REPEAT
INPUT"ANOTHER POSTING NUMBER TO PRINT TO FILE OR Q TO quit";A$
IF A$="Q" OR A$="q" PROC_quit
C$=" #"+A$+" "
x=OPENIN "all_postings2.doc"
PRINT" Please Wait Please Wait Please Wait Please Wait"
REPEAT
A$=LEFT$(GET$#x,LENC$)
UNTIL A$=C$ OR PTR#x=EXT#x
*SPOOLON T.TXT
PRINT
PRINT" xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxx
xxxxxxxxxxxxx "
PRINT
REPEAT
IF A$<>"" PRINT A$
A$=GET$#x
UNTIL LEFT$(A$,40)="Reply | Forward | Messages in this Topic" OR
PTR#x=EXT#x
PRINT
*SPOOL
IF PTR#x=EXT#x PRINT "NOT FOUND "
CLOSE#x
PRINT
UNTIL y$="stop"
PROC_quit
STOP
DEF PROC_quit
OP$="notepad.exe "+file$
OSCLI OP$
QUIT
ENDPROC
Hi All, In continuing response to Phil's post #290
>Other hardware project ideas -
When I saw it suggested surfing the web I didn't believe it. It seemed like using a sledge hammer to crack a nut. The tip to remove ICs from a circuit board was to use an electric heat gun the type used in DIY to strip paint. Use the high setting in my case that was 600w but 500w is ok. On the other side of the board use pliers or an IC extracter. I tried it 10 seconds to remove a chip. Not a mark left on the board. Up until then I had spent a lot of time using the traditional method of a soldering ion and solder sucker. It was hit and miss some removed ok. Just as many were stubbon and got cooked useless. Some are still left stuck in the board ruined surrounded by soldering iron burn marks.
The dred of having no alternative to remove an IC from a board has gone. So folks, before chucking those old boards get out the heat gun. And if you need a chip post a wanted to the group.
We have talked about a lot of diverse things over the last couple of years. One problem arising from this is that the message board is not optimised for threads - so it's really hard to keep track of topics and the 'state of play' with a particular discussion - especially if they are left for awhile and returned to. Since it is in the nature of the tinkering that we are all engaged in, one way or another, that we dip in and out of topics - some way of tying this up better would be great. Beggars cannot be choosers and we are stuck with the format of the messageboard. I wonder if Chris could be prevailed upon (or more considerately, someone else might volunteer) to get a listing of all the posts and sort them chronologically under discussion threads. These could be posted as a zip and be downloadable from the files section. The first one would be a lot of work, but if it were then done quarterly it would be a fairly simple and quick job?
Other hardware project ideas - As you know the Einey has an internal clock supported by the CTC. In a previous incarnation I had an Einey with a real time clock piggy- backed onto the z80 Cpu - it was a Texas Intruments package and I developed routines to date and time stamp files. I believe the person who developed it is no longer with us, and my DOS (that used it) was destroyed. I believe the chip is still available and is dirt cheap. It was mounted on a chip holder which was soldered to the CPU and drew power from it - it was able to feed date and time info direct onto the bus via a port setting. If we develop XTAL dos further to support big drives and directories then Date Time stamping will become essential.
Ram - this has been talked about before. The Z80 supports very fast pageing in chunks of up to 64kb, this is why the ROM works. This is how the silicon disc worked once upon a time. This is how banked CP/M 3 works. For an electronics person taking some large chunks of RAM, sticking them on the bus, and integrating some chip select multiplexing is probably no more difficult than any of the other the fine work that's been done to date. Imagine being able to run concurrent programs, imagine how powerful the OS could become if it had its own 64k page, imagine having a common data page, imagine having a 64k TPA for each of your running applications,imagine being able to grab an extra few 64kb pages of memory for your application when you wanted them, imagine being able to store the FAT of a large hard drive in its own memory page... The software to enable and select paging is very simple and could be implemented in a BDOS call.
There is a Zilog chip called the Z180A? - not sure. It's pin compatible with the Z80A - but it runs at 8Mhz. A little bird told me once upon a time that to get it to run on the Einstein all you need to do is replace the CPU and the oscillator crystal (to 8Mhz) and everything works a treat - at twice the speed :)
Finally, is anyone else here sad enough to want to meet up at a convention sometime i.e. have our own meeting somewhere where we can bring our stuff, chat and see what every one else up too?
No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.6/1402 - Release Date: 4/28/08 1:29 PM
#290 From: "fil_simmons" *|I wonder if Chris could *|be prevailed upon (or more considerately, someone else might *|volunteer) to get a listing of all the posts and sort them *|chronologically under discussion threads. *|These could be posted as a *|zip and be downloadable from the files section.
I'm not sure how best to do this. As Phil has said the message board is not optimized for threads as with other forum groups I've visited where a choice of thread titles is given to post to. With yahoo groups if a post is made as a reply to another posting it becomes part of that thread, if a post is sent as a new post its classed as new thread. It will remain a stand alone post unless some one else posts a reply to it.
How threads are made with yahoo depends on how an individual member makes their posting. To get posts structured into yahoo discussion threads it really needs the member making the post to first consider whether it would be better to post it as a reply to an existing post. Even possibly in making a reply to one of their own previous posts.
When a reply to an existing post is made it appends the original post to it. I'm not sure how to consider this - good or bad. It does duplicate messages useful for reference to another post but when reading posts in a thread online it just duplicates the same text which is in the next post of the thread to read.
Up until now I've more of less just waited until postings have come down to my inbox and rarely ever glanced on line at group messages. Inbox e-mails from the group do not show the post number. Online a post number is shown prefixed by "#" which is in chronological order of all postings sent. This can be used to make references to other posts. Selecting individual message text for copy and paste online I've now found simpler than opening outlook express, selecting an e-mail and then copying that to a text editor. The former will also show the post number the latter doesn't.
Online Yahoo Groups provides a search facility for specific text and lists all the posts its in. Unfortunately messages from a search can not be expanded so select copy and paste to a text editor will not show all message content but making a note of post numbers can be made.
Example: For search text "Fpga" can be found in posts 42 51 52 53 54 55 56 60 70 71 86 89 116 221 222 227 228
Getting a text copy of all messages posted to the group so far has been easy and quick its been uploaded to the files root folder as all_postings.doc size 146kb this will load into M/s WordPad. A previous up upload with a TXT extension has been deleted as it opened up in the browser window, was too large to cut and paste to NotePad and wouldn't paste into WordPad.
The question how to get messages listed into discussion threads? Another question could be which messages should be in which thread and who decides. A message that one person thinks should be in one thread another person might think it to be in another.
I don't want rules made up to how posts should be made. Or even to be seen to be advising as to how posts should be made. This for some members especially new members could discourage them from making posts.
I think the best thing for the moment is to let members, who want to, read the messages in all_postings.doc or online at the Yahoo Group and make up their own listing of post numbers of messages they consider should be grouped together. They can post their listing of message numbers to the group or copy and paste their selection of messages into a document file and upload it to the group files and/or can add their own comment.
From what is contributed there might be seen a clear and obvious way to go forward.
We have talked about a lot of diverse things over the last couple of years. One problem arising from this is that the message board is not optimised for threads - so it's really hard to keep track of topics and the 'state of play' with a particular discussion - especially if they are left for awhile and returned to. Since it is in the nature of the tinkering that we are all engaged in, one way or another, that we dip in and out of topics - some way of tying this up better would be great. Beggars cannot be choosers and we are stuck with the format of the messageboard. I wonder if Chris could be prevailed upon (or more considerately, someone else might volunteer) to get a listing of all the posts and sort them chronologically under discussion threads. These could be posted as a zip and be downloadable from the files section. The first one would be a lot of work, but if it were then done quarterly it would be a fairly simple and quick job?
Other hardware project ideas - As you know the Einey has an internal clock supported by the CTC. In a previous incarnation I had an Einey with a real time clock piggy- backed onto the z80 Cpu - it was a Texas Intruments package and I developed routines to date and time stamp files. I believe the person who developed it is no longer with us, and my DOS (that used it) was destroyed. I believe the chip is still available and is dirt cheap. It was mounted on a chip holder which was soldered to the CPU and drew power from it - it was able to feed date and time info direct onto the bus via a port setting. If we develop XTAL dos further to support big drives and directories then Date Time stamping will become essential.
Ram - this has been talked about before. The Z80 supports very fast pageing in chunks of up to 64kb, this is why the ROM works. This is how the silicon disc worked once upon a time. This is how banked CP/M 3 works. For an electronics person taking some large chunks of RAM, sticking them on the bus, and integrating some chip select multiplexing is probably no more difficult than any of the other the fine work that's been done to date. Imagine being able to run concurrent programs, imagine how powerful the OS could become if it had its own 64k page, imagine having a common data page, imagine having a 64k TPA for each of your running applications,imagine being able to grab an extra few 64kb pages of memory for your application when you wanted them, imagine being able to store the FAT of a large hard drive in its own memory page... The software to enable and select paging is very simple and could be implemented in a BDOS call.
There is a Zilog chip called the Z180A? - not sure. It's pin compatible with the Z80A - but it runs at 8Mhz. A little bird told me once upon a time that to get it to run on the Einstein all you need to do is replace the CPU and the oscillator crystal (to 8Mhz) and everything works a treat - at twice the speed :)
Finally, is anyone else here sad enough to want to meet up at a convention sometime i.e. have our own meeting somewhere where we can bring our stuff, chat and see what every one else up too?
No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.6/1402 - Release Date: 4/28/08 1:29 PM
Just to let folk know I'm an avid follower of the groups progress. Thanks.
Just waiting for the space to reinstall my Eineys again.
Bob
On Tue, Apr 29, 2008 at 1:36 PM, Chris Coxall <albertstc01@...> wrote:
> Hi All,
>
> Over the time that I've been involved with the Einstein community
> I've known enthusiasts to be absent from contact for long periods
> only for them to reappear after researching and developing Einey
> projects of benefit to all of us.
Hi All,
In the library today - so I have internet :)
We have talked about a lot of diverse things over the last couple
of years. One problem arising from this is that the message board is
not optimised for threads - so it's really hard to keep track of
topics and the 'state of play' with a particular discussion -
especially if they are left for awhile and returned to. Since it is
in the nature of the tinkering that we are all engaged in, one way
or another, that we dip in and out of topics - some way of tying
this up better would be great. Beggars cannot be choosers and we are
stuck with the format of the messageboard. I wonder if Chris could
be prevailed upon (or more considerately, someone else might
volunteer) to get a listing of all the posts and sort them
chronologically under discussion threads. These could be posted as a
zip and be downloadable from the files section.
The first one would be a lot of work, but if it were then done
quarterly it would be a fairly simple and quick job?
Other hardware project ideas -
As you know the Einey has an internal clock supported by the CTC. In
a previous incarnation I had an Einey with a real time clock piggy-
backed onto the z80 Cpu - it was a Texas Intruments package and I
developed routines to date and time stamp files. I believe the
person who developed it is no longer with us, and my DOS (that used
it) was destroyed. I believe the chip is still available and is dirt
cheap. It was mounted on a chip holder which was soldered to the CPU
and drew power from it - it was able to feed date and time info
direct onto the bus via a port setting. If we develop XTAL dos
further to support big drives and directories then Date Time
stamping will become essential.
Ram - this has been talked about before. The Z80 supports very fast
pageing in chunks of up to 64kb, this is why the ROM works. This is
how the silicon disc worked once upon a time. This is how banked
CP/M 3 works. For an electronics person taking some large chunks of
RAM, sticking them on the bus, and integrating some chip select
multiplexing is probably no more difficult than any of the other the
fine work that's been done to date. Imagine being able to run
concurrent programs, imagine how powerful the OS could become if it
had its own 64k page, imagine having a common data page, imagine
having a 64k TPA for each of your running applications,imagine being
able to grab an extra few 64kb pages of memory for your application
when you wanted them, imagine being able to store the FAT of a large
hard drive in its own memory page... The software to enable and
select paging is very simple and could be implemented in a BDOS call.
There is a Zilog chip called the Z180A? - not sure. It's pin
compatible with the Z80A - but it runs at 8Mhz. A little bird told
me once upon a time that to get it to run on the Einstein all you
need to do is replace the CPU and the oscillator crystal (to 8Mhz)
and everything works a treat - at twice the speed :)
Finally, is anyone else here sad enough to want to meet up at a
convention sometime i.e. have our own meeting somewhere where we can
bring our stuff, chat and see what every one else up too?
Hi All,
Over the time that I've been involved with the Einstein community
I've known enthusiasts to be absent from contact for long periods
only for them to reappear after researching and developing Einey
projects of benefit to all of us. There are also less fortunate
reasons where active contact has to be put aside for a time for the
fear that Einey interest and enthusiasm will be a distraction for
dealing with other important personal issues such as employment and
family. Members of this group can have varying depths of Einstein
interest and should be able to make postings, not make postings or
just be a passive observer without fear of embarrassment. So please
apologies for absence are not required.
If postings to the group have become sparse then from Phil's latest
post for what is to come, for example (100 documented pages with a
detailed commentary on every routine) will be well worth the wait.
This will be useful information and complementary to making good use
of the compact flash interface that Geoff has shown to work.
I have made an attempt to interface the CF with unfortunate results.
My eyes are not as good as I would like them to be or my hands as
steady. Soldering the closely pitched pins of a CF holder seemed a
bit ambitious for me so I had the idea to push wires into the CF to
hold them in place then use super glue along the rows of wires to
make a rigid and manageable adapter. It may well work but in my case
the glue flooded out the tube and glued not only the wires but wires
to the CF and the CF to the work bench. One useless CF for my efforts.
A problem with hardware developments are that many of us are not
capable when things become too intricate. Ways need to be found to
make building hardware less fiddly even at the expense of a lack of
compactness. With a suggestion from one of Geoff's posts to use a CF
to IDE adapter I had a look on Ebay.
Regularly auctioned
3 x CF to IDE Compact Flash Adapter Male Bootable B03
Buy it now price: £0.99 Postage costs: £3.99
Seller xiandaixg
Just 2P short of £5 for three seems pretty good to me.
Up on the internet I found a pinout for the CF/IDE adapter at
http://pinouts.ru/DiskCables/ide2cf_cable_pinout.shtml
Another problem I had in making up development board for tatung pipe
projects using solder less breadboards was that I wanted to work on
the board in front of the Einstein monitor. The ribbon cable from the
pipe to the front of the computer seemed to be too long to maintain
signal strength. So how close does the CF need to be? The problem of
neatly housing addons becomes more difficult if things just have to
dangle off the pipe.
Another hardware project of my own.
I've made up a link between the Einstein's printer and user port to
the PC printer port. My initial intention to create the link and
machine code hand shaking routines that can be called from basic both
on the Einstein and PC to transfer one byte reliably. I'm leaving
others to decide how the routines can be repeatedly called to chain
bytes for use in their own programming. I've used the byte sending
routines to open a text file on the PC and have it displayed on the
Einstein screen. I have done so as a demonstration and test for
myself to make sure no bytes were missing or duplicated. On the PC
I'm using Bbcbasic for Windows.
I was hoping the link would be a straight forward wiring job but as
Muphy's law would have it this was not how it has become at the
moment. There are a number hidcups which make the link more
complicated.
Hidcup 1: In mode 1 port A the printer port has two hand shaking
lines strobe and acknowledge but there isn't a register where these
handshakes can be read or set. The PIO appears to have its own
automatic hand shaking built in. The strobe hand shake is an output
and I have it attached to the ACK pin on the PC which can be polled
from the status register. There is not a way though to monitor the
input to the Einstein on port A's acknowledge pin. A programming loop
to read port A's data port can't be held for not being able to read
the Acknowledge pin status. Without this ability the same data byte
is read repeatedly instead of waiting for a new byte sent. In the Z80
PIO manual it says the raising edge of the strobe (an import to
acknowledge pin on port A) generates an interrupt (if it has been
enabled). It seems to get the kind of hand shacking required more
sophisticated programming using the interrupt will be needed. Until I
can find a working program example or work out by trial and error how
it can be done I've put using mode 1 aside.
I am instead successfully using port A Einey's printer port and port
b the user port to transfer data. Data from the PC printer port is
sent to port A Einstein's printer port and strobe from the PC to bit
2 busy in the Einey auxiliary register. I'm using port b Einey user
port line 2 bit 0 to toggle acknowledge on the PC.
Hidcup 2: Unfortunately this is not straight forward wiring. Data
outputs from the user port is low in voltage and needs additional
circuitry to make the voltage high enough to set acknowledge on the
PC.
Using port B might make the link more complicated but there is an
extra potential. There are 5 line inputs to the PC status register.
ACK will be needed for normal hand shaking but the other four could
be set by the Einstein's user output for the PC to read 15 different
values for a menu to run different communication services. The user
port could also be used by the Einstein to read 3 bit imports in
addition to strobe from the PC's control port.
Hidcup 3: My present programming on the PC uses access directly to
the I/O registers of the printer port. This is OK with win95 & win98
but it will not work with XP or win2k. BBC4W comes with a third party
utility WINIO which can be used directly for reading and writing to
I/O ports using BBC4W with XP and win2k. I tried using it but it
seemed unreliable some times working some times not. I need time to
read the WINIO documentation if I can understand more fully how it
operates I might see what the problems are.
Once I've decided on the best option to use I'll post hardware and
software details to the group and create a web page for the web site.
I also want to get a CF attached to my Einstein with Geoff's
interface and put the details of the build and software to read and
write to CF sectors up on the web site. For a web site surfers the
build will have to be simple as possible and the mounting and housing
a neat and tidy construction. Something as good as Jose's external
3.5 floppy he built in a vidio case.
Regards Chris Coxall
Hi All,
Recently I said that I had nearly completed the disassembly of the
Xtal Dos CCP (Console Command Processor), the bit that does the
command line procesing, and that I had started on the BDOS portion
and that I hoped to complete this by the Autumn.
Well I'm pleased to say that the BDOS disassembly is nearly finished
too! The reason is that it occured to me to compare Xtal Dos to the
source code for CP/M 2.2. I have a copy of this. It was never
optimised for Z80, merely copied from the 8080 intsruction set which
is a subset of Z80 machine code.
Guess what! The Xtal Dos code is about 85% identical to CP/M 2.2.
Apart from raising an interesting historical question (did Xtal
license CP/M code from Digital Research or did they reverse engineer
it?), it means that it's saved me a huge amount of work. So the
chances are the now the whole thing will be posted sooner than later.
Having said this I have decided to rework some of the CCP disassembly
so that the labels conform more closely to those of CP/M 2.2 - this
should help anyone else who wants to compate the two OS's. Since I did
the CCP entirely from my own head the labels are different at the
moment. So I won't now be releasing the CCP until this is done. The
entire piece of work is going to be in excess of 100 documented pages
with a detailed commentary on every routine, so it's still a
substantial chunk of work to get through, please be patient :)
I apologise for not posting the forumn more frequntly and being slow
to answer any postings, I don't actually have a phone or an internet
connection so I have to venture to civilisation once in awhile to
post. Also my laptop is broken at the moment. Soon I'll be moving
closer to other beings and the joys of modern technology will once
more be available to me - can't wait :)
Parallel port connections. Update.
Hi Geoff,
Still no success with hand shaking using mode 1 on port A the port
used for the Einey printer port.
I have though established parallel port import with hand shaking from
the PC printer port by using port A for data and polling bit 2 busy
in the Einey auxiliary register and using port b Einey user port line
2 bit 0 to toggle acknowledge on the PC.
Both ports are used in mode 3; port A set for 8 bit import; port B
bit 0 for output. The data output pin from the user port was only
3.4v multi metre reading not enough to put acknowledge high on the
PC. To get it to higher voltage the data line was put through a
74ls244 (an 8 line buffer)taken off an old Einey mother board. VCC
for the IC came from the 5v pin 1 of the user port. After the IC the
voltage was still 3.4v so a 1k resister was used to pull up to the 5v
from pin 1 (I think a 2k should be used here). This brought the
output up to around 4v enough to set acknowledge on the PC. The
74ls244 might not be needed just the pull up resister but I'm
guessing the IC gives Einey some protection against to much power
back feeding.
I have programming on the PC and Einey to receive streams of data to
Einey without bytes missing or duplicating.
As a test for data output power levels from Einey's port A to the PC
I used some simple programming for Einey to send and the PC to
receive. Einey streamed data over to the PC ok (no hand shaking
established here yet) but it shows no additional hardware circuitry
is needed for data lines for the PC.
Regarding mode 1: A multi metre test on the printer port showed
strobe pin 1 of printer port connected to Aready of the z80 pio to
have a healthy 5v. Enough to hold acknowledge high for the PC. With a
connection to the PC there is no sign of strobe going low with a
negative pulse. This should happen when strobe from the PC to
acknowledge pin 19 (connected to ASTB of z80 PIO) goes from low to
high. Triggering on the rising edge.
A test I can try later (when I can disconnect my present improvised
connection) is to use strobe pin 1 to power a LED.
run the program
10 PUT &31,&4F
20 N=GET(&30)
30 PRINT N
40 GOTO 20
Then touch the line attached to acknowledge pin 19 to 5v an see if
the LED blinks off.
Given that this works unlike my present set up where I have
programming polling control over monitoring hand shaking inputs and
setting handshaking outputs-: mode 1 hand shaking is invisible to the
programmer. There is no control in mode 1 to read the state of
acknowledge or set a hand shake to the peripheral. The only way I can
see mode 1 handshaking to be effective is that the programming to
import a byte as above or its machine code equivalent is only run
when triggered by an interrupt.
I'm still mode 1 confused.
Regards Chris Coxall
Hi phil,
I don't know if anyone already sent you this but I've just found my
ZBASIC disk. The attached inage was made with CPCDiskXP v1.6
If you have any problems with it just let me know.
Regards,
Geoff
Hi Chris,
Thanks for the update.
I know the Einey user port is TTL level (can't remember the specs) and
I thought that the PC Parallel port was the same but I know there are
sometimes problems interfacing the parallel port. I'll look into it.
I'm going to be trying to boot into DOS from a compact flash card
later this week and will let you know how things go.
Regards,
Geoff
Hi Geoff,
Thanks for the info and the tests you've done.
From your tests it seems to me now clear that the Einey side
of mode 1 does work with the specified hand shaking. I made
this assumption a couple days ago and thought I had better
check out the PC side of things.
In brief: On the Einey I set up the port b in mode 3 set bit
0 pin 2 for output the rest left as inputs. I made a circuit
using 303 resister and a LED connected to data pin 0. The
LED lit up but not very brightly.
If I connected the LED circuit to 5v pin 1 of the user port
the LED came on much brighter.
I tried an analog switch TC4016BP ic scrimped off an old
Einey mother board connecting 5v pin 1 through the IC to the
LED and data pin 2 bit 0 of the user port to the gate of the
IC the LED lit but only dimly.
Next I connected a wire from 5v pin 0 to the gate of the IC
the LED lit up bit more brightly but not as bright as
directly connecting the LED circuit to 5v pin 1.
It seems the outputs of the user ports are week on power.
With the above knowledge I tried the connections to the PC
printer port. Just a connection for ground and pin 10
Acknowledge of the centronics plug on the printer cable
connected to the PC.
On the PC I have a program running which sets the ECP
parallel port to byte mode and pols the status port for the
state of acknowledge.
Here is an irritation! Information off the web says that
reading the inputs of the status port will always show high
if there is nothing connected to the port. No one seems to
be saying how the PC is to know that there is something
connected. Never the less after fiddling with wires my
program does read acknowledge as low when there is no power
supplied to the acknowledge pin.
Ok connecting 5v pin 1 of the user port to pin 10
acknowledge for the PC printer port does get my program
polling acknowledge as high and disconnecting puts it back
to polling low.
Connecting the output pin 2 data bit 0 to acknowledge makes
no difference. As with LED circuit I tried to use the data
output as a gate switch for the IC with power from pin 1 5v
going through IC to acknowledge. This did not work. Putting
5v from pin 1 onto the gate of the IC also didn't work.
I tried a transistor of unknown specs this did not switch
power with data pin going to the gate but did when I wired
5v from pin 1 to the transistor base.
It seems outputs from the user ports are too week in
themselves to register on the PC printer port.
Volt meter reading for data pin 0 was around 3.4v for pin 1
4.94v.
Surfing for answers on the web there is a suggestion that an
op-amp would be the option to boost power on week out put
lines. If I can find one I'll try this.
Many Thanks for your time and effort.
Regards Chris Coxall
Hi Chris,
Further to my tests with the User Port, there's some code here
http://www.alioth.net/Projects/Z80/piotest-intr.asm to use the
interrupts from the PIO chip but for a different computer. Everything
should be accessible in the Einstein. I see no reason for anything to
not be enabled.
In XBasic the command you might need to use is WAIT instead of INP. I
can't find my BBC Basic reference guide at the moment but there should
be a similar command.
The WAIT command is followed by 3 numbers, ie;
20 WAIT J1,J2,J3
J1 is the port number (&32 for User Port)
J2 and J3 are used to compare the data from the port with a user
specified scheme and return a result if there is a match.
1. Get data from port.
2. XOR with J3
3. AND with J2
4. continue if result is non-zero
But I don't think that's really what you intended. If you need to pass
a stream of data from the PC to the Einstein with handshaking in
Basic you need some form of the INPUT# command and set it to read data
from the User port, or do it in assembler.
The code in the page I linked to above can be changed for the Einstein
(including but not limited to);
First, change the port addresses
-----
; Port and function - place one of these on the address bus.
DEFINE PortA_DATA #30
DEFINE PortA_CMD #31
DEFINE PortB_DATA #32
DEFINE PortB_CMD #33
-----
You might also need to change the org, Stack Pointer and VectorTable
Second, set up the port for input instead
-----
SetupPIO
ld a, Input ; Put PIO port A into input mode
-----
Third, re-write "BlinkerLights" and the "PortA_Intr" to read a stream
of data and display it.
I'll leave that bit up to you.
Regards,
Geoff
damn the computer crashed and I have to re-type.
Einey running in X5 (XTAL Basic V5)
10 OUT &33,&4F
20 A=INP(&32)
30 PRINT A
40 GOTO 20
I made a 16 way IDC lead with a PC floppy lead, a hacksaw and some
superglue. It works well.
I connected all the data lines of the user port together (looking into
the user port from the back D7, 5v, D6, 0v, D5, STB, D4, 0v, D3, 0v,
D2, RDY, D1, 0v, D0, 5v ) and stripped back the 5v, 0v and STB
(strobe) lines.
NOTE; the program streams data from the user port regardless of
whether the input has been updated or not.
The program streams 255, 255, 255, etc.
I connected all the date lines to 0v and tapped the STB to 0v.
The program streams 0, 0, 0, etc.
I connected all the data lines to 5v and tapped the STB to 0v
The program streams 255, 255, 255, etc.
I believe the RDY line goes high after the data has been read once (or
many times) but I can't test that at this time on night after this
amount of Gin.
Your previous program in BBC Basic should be fine
10 PUT &33,&4F
20 N=GET(&32)
30 PRINT N
40 GOTO 20
..but your assumption that pulling STB high would stop the stream was
incorrect. As you can test from the above example the handshaking
works as you can spend time setting the bits high and low as you
desire (try "High, High, High, High, Low, Low, Low, Low") and only
register the changes when you pulse the STB line low.
I'll look into setting the port to cause an interrupt when data is
received, but not after this amount of Gin :)
Hope this helps.
Regards
Geoff
Hi,
Would someone be kind enough to send me a .dsk image of ZBasic ver
3.xx for the Einey.
I did pay for a copy of this a year ago from B&H Computers but it
never arrived and the guy refuses to answer my
e-mails. I don't want to do everything in assembler and sometines Z
is handy.
cheers
Phil
Hi Geoff,
I'll download it and have a look.
Cheers Phil
--- In tatung_einstein@..., "geoff" <geoff@...> wrote:
>
> Hi Phil,
>
> I've uploaded some initial code and notes for an IDE and CF
version of
> the MCAL ZRBLK. It would just replace the ZRBLK call in your code.
>
> It's only initial ideas and not proper code (I don't even know if
the
> syntax is right as I've never done any Z80 assembler before.) all
> thoughts and corrections are welcome
>
> It uses the same registers and memory as your EFL and when I get
time
> to check the code and correct my many errors I'll merge the two
for a
> quick test.
>
>
>
> Regards,
> Geoff
>
>
> --- In tatung_einstein@..., "Phil Simmons"
> <phil_simmons@> wrote:
> >
> > Hi Geoff,
>
Hi Geoff,
A bit map of Einey mother board can be downloaded from the web site.
http://mysite.wanadoo-members.co.uk/retrocomputer/download.htmhttp://mysite.wanadoo-
members.co.uk/retrocomputer/download/mb_wiring.zip
Thanks for the correction.
I was using the wrong pair of glasses miss read &47 for &4F in the
Einey Mags.
Unfortunately making a change made no difference.
I don't know if my theory is right but I tried this test.
I ran this BBCBASIC prog on Einey for the user port without anything
connected to it.
10 PUT &33,&4F
20 N=GET(&32)
30 PRINT N
40 GOTO 20
The value of N variable 253 streamed down the screen probably a
default value.
According to the Z80 PIO manual if a steady high is applied to STB
pin 11 without a negative pulse the data from the port should not be
accessed.
To test I crossed pin 11 STB with pin 1 5v. The streaming didn't stop.
I think the Z80 PIO handshake for mode 1 and 2 on Einey has been hard
wired out for normal access just leaving line input and output. STB &
RDY for the port a must be available for Einey's printer driver. So
it might be available with some other configuaring.
This extract from the Tatung Einstein Hardware Manual
might hold the answere.
Parallel Input/Output (Printer and User I/0)
The PIO has two 8 bit parallel ports which can be used as
either inputs or outputs under software control. Port A is
dedicated as a printer output by the MOS at power-on, and
this port has a monostable (1053b) which provides a (lus)
pulse triggered by the Ready (ARDY;I063 pin 18) line of the
PTO port A and is fed to the STROBE output (M001, pin 1).
This pulse is needed to comply with the Centronics printer
-interface timing. As well as the eight data-line outputs
(1063 pins 7,8,9,10,12,13,14,15) which are fed direct to the
printer connector (M001 pins 3,5,7,9,11,13,15,17
respectively). there are three "handshake" input lines from
the printer connector BUSY, PAPER EMPTY, ERROR (M001 pins
21,23,28) which are connected to the tri-state buffer 1036
(pins 15,13,11) to allow printer error conditions to be
detected. The even-numbered pins of the printer connector
(M001) are connected to OV.
The data-lines from port B (1063 pins
27,28,29,30,31,32,33,34) are connected to the user 1/0
connector (M002, pins. 2,4,6,8,10,12,14,16) and the Ready
(BRDY; I063 pin 2) is connected to M002 pin 5. Strobe lines
from each connector (M001, pin 19 and M002 pin 11) are
connected to pull- up resistors R057 and R058 as well as the
strobe inputs of the P10 (ASB,BSTB; 1063 pins 16,17
respectively)
Try to make sense of it later.
Thanks for your help.
Regards Chris Coxall
Hi Chris,
I think I was was wildly wrong earlier (depending on how things were
implemented in the Einstein). Mode 1 should handle the handshaking. I
did, however notice a discrepancy between your control code and the
one listed in the docs.
The PIO doc mentions that to set the mode the control code must use
the two most significant bits for the mode number (ie 01 for mode 1),
then two unused bits (set to 00), followed by the last nibble all 1
(to indicate you want to set the Mode and not issue a different
command) making 01001111 or &4F not &47 as you had in your message. If
the last 4 bits were set to 0111 (&7) then the PIO will think the
control code is for setting interrupts (or ignore it as it would have
been sent at the wrong time)
So to use Parallel Port A (the printer port) in Mode 1;
OUT (&4F,&31) - To send &4F to the printer control register at &31
IN (&30) - To read from the printer data register at &30
(that's for Basic, in assembler the op codes are OUT and IN but the
syntax is obviously different depending on the assembler)
To do the same for Parallel Port B (the User Port) you'd send the
control code to &33 and read data from &32.
Let me know if this helps. I have assumed that the PIO is wired up in
the Einstein in a standard format. I don't have a schematic for the
main board so can't check without opening one up. I have also assumed
that there is nothing stopping input from the printer port.
Regards,
Geoff
> In my Einey Mag back numbers lots of info on using mode
> 3-control mode. Nothing on mode 2. For mode 0-only mentions
> to set mode 0 by an OUT to the control of &0F. For mode
> 1-only mentions to set mode 1 by an OUT to the control of
> &47. There isn't any programming examples for mode 0 or 1.
>
> Any help appreciated.
>
> Regards Chris Coxall
>
Hi Chris,
Mode 0 Either A or B as 8-bit output (active strobe after output)
Mode 1 Either A or B as 8-bit input (triggering interrupt request if
enabled)
Mode 2 Port A bidirectional plus interrupts and handshakes.
Mode 3 Both Ports individual bits defined as input or output, interrupts
used.
I could be wrong but it looks like you need to use Mode 2 to use
handshaking.
Geoff
Chris Coxall wrote:
>
> Hi,
>
> Does anyone have programming examples of using the Einstein
> user ports in mode 1 (eight bit import) in their Einey Docs.
>
> >From the Z80 PIO tech doc (can be found at
> http://mysite.wanadoo-members.co.uk/eineydocs/erdhsm.html
> <http://mysite.wanadoo-members.co.uk/eineydocs/erdhsm.html>)
>
> "Selecting Mode 1 puts the port into the input Mode. To
> start handshake operation, the CPU merely performs an input
> read operation from the port. This activates the Ready line
> to the peripheral to signify that data should be loaded Into
> the empty input register. The peripheral device then strobes
> data into the port input register using the strode line.
> Again, the rising edge of the strobe causes an interrupt
> request (it has been enabled) and deactivates the Ready
> signal. Data may be strobed into the input register
> regardless of the state of the Ready signal if care is taken
> to prevent a data overrun condition."
>
> I've linked a printer cable between a PC and Einey's printer
> port 8 data lines and swopped over the strobe and ACK lines.
> Strobe goes from PC to Einey's printer port's ACK pin 19 as
> listed in the Einstein Introduction manual. I know if I had
> used the user port Z80 PIO's B port Strobe from the PC would
> have gone to STB pin 10 of the user port as listed in
> Einstein Introduction manual and RDY to PC's ACK. But Ive
> used the printer port and set that as mode 1 which is wired
> to PIO.
>
> Data streams across from the PC ok but there is no hand
> shaking as specified by the tech doc. Get a lot of duplicate
> bytes.
>
> It could be that the Z80 PIO's hand shaking facility for
> mode 0 and 1 have not been made available for the Einstein.
> Or more probable I've missed something in the set up
> programming. If is this is the case the tech doc has not
> been helpful.
>
> In my Einey Mag back numbers lots of info on using mode
> 3-control mode. Nothing on mode 2. For mode 0-only mentions
> to set mode 0 by an OUT to the control of &0F. For mode
> 1-only mentions to set mode 1 by an OUT to the control of
> &47. There isn't any programming examples for mode 0 or 1.
>
> Any help appreciated.
>
> Regards Chris Coxall
>
>
Hi,
Does anyone have programming examples of using the Einstein
user ports in mode 1 (eight bit import) in their Einey Docs.
From the Z80 PIO tech doc (can be found at
http://mysite.wanadoo-members.co.uk/eineydocs/erdhsm.html)
"Selecting Mode 1 puts the port into the input Mode. To
start handshake operation, the CPU merely performs an input
read operation from the port. This activates the Ready line
to the peripheral to signify that data should be loaded Into
the empty input register. The peripheral device then strobes
data into the port input register using the strode line.
Again, the rising edge of the strobe causes an interrupt
request (it has been enabled) and deactivates the Ready
signal. Data may be strobed into the input register
regardless of the state of the Ready signal if care is taken
to prevent a data overrun condition."
I've linked a printer cable between a PC and Einey's printer
port 8 data lines and swopped over the strobe and ACK lines.
Strobe goes from PC to Einey's printer port's ACK pin 19 as
listed in the Einstein Introduction manual. I know if I had
used the user port Z80 PIO's B port Strobe from the PC would
have gone to STB pin 10 of the user port as listed in
Einstein Introduction manual and RDY to PC's ACK. But Ive
used the printer port and set that as mode 1 which is wired
to PIO.
Data streams across from the PC ok but there is no hand
shaking as specified by the tech doc. Get a lot of duplicate
bytes.
It could be that the Z80 PIO's hand shaking facility for
mode 0 and 1 have not been made available for the Einstein.
Or more probable I've missed something in the set up
programming. If is this is the case the tech doc has not
been helpful.
In my Einey Mag back numbers lots of info on using mode
3-control mode. Nothing on mode 2. For mode 0-only mentions
to set mode 0 by an OUT to the control of &0F. For mode
1-only mentions to set mode 1 by an OUT to the control of
&47. There isn't any programming examples for mode 0 or 1.
Any help appreciated.
Regards Chris Coxall
Hi Phil,
I've uploaded some initial code and notes for an IDE and CF version of
the MCAL ZRBLK. It would just replace the ZRBLK call in your code.
It's only initial ideas and not proper code (I don't even know if the
syntax is right as I've never done any Z80 assembler before.) all
thoughts and corrections are welcome
It uses the same registers and memory as your EFL and when I get time
to check the code and correct my many errors I'll merge the two for a
quick test.
Regards,
Geoff
--- In tatung_einstein@..., "Phil Simmons"
<phil_simmons@...> wrote:
>
> Hi Geoff,
I'll try to answer your questions as clearly as possible.
1. Regarding the Read Sectors routine -
This is just used to load the fat, directory and boot file from the floppy disk into memory. As you have correctly understood - EFL doesn't write the code for you it just simplifies booting a file from a fat structure. What you want to do is write code to be placed in the boot file to handle your access to the CF card. Think of it as a mini OS. Using the example of EFL you could write code to create a fat for your CF card and then write a few functions to use the card e.g.create_file, read_sectors and write_sectors. Place this code in the XCOMMAND.BIN file.
You could alter the load address used by EFL to boot your code into high memory. You could then load some code at 100H ie. a program, to play with and test the functions you have written. The two routines which you may find directly useful are CLUSTER2LBA and LBA2CHS which translate between LBA and CHS adressing - To keep things simple I only used track and sector addressing but say, a hard disk, would also use head addressing in CHS mode. Since LBA can simply use sector addressing this is the simplest and (these days) most universally compatible method. A logical sector is just a physical sector adjusted by for the sectors offset of the fat and directory - in EFL the data section starts at logical sector 0.
So, yes you are correct - a rewritten subroutine along the lines of Read Sectors but specifically for the CF card would be one such function - with the qualifier that it reads from the CF cards own fat.
Ultimately I would envisage the developed LBA low level disk routines as MOS routine counterparts of the floppy functions to be added to an expanded EPROM -
MOS 2.0? :) These would then be called by the CBIOS of whatever operating system is developed.
A tip : Creating a FAT for your CF card is dead easy. All you have to do is calculate and reserve the number of sectors that will hold all of the FAT words to address the entire card. As EFL is just Fat 16 at the moment you might have to use large cluster sizes or partition the card into smaller virtual drives.
Because a fat is just a linked list of cluster pointers, a new unused fat is just a sequential series. So all you have to do is write words 1,2,3,...nnn in order, to your reserved sectors and there is your fat, ready for action. (0 points to 1, 1 points to 2 etc.) It is also useful to keep a a tracking variable called something like FirstFree which as its name suggests, always points to the first free cluster in the chain - useful when creating a new file.
2. Yes! You add additional files to the Root directory exactly as you described. Remember to reduce the directory space tail by 32 bytes for each additional entry.
So once you have formatted YCOMMAND.BIN you have DS (512*8)-64,$E5 to the end of the Directory.
Finally the Data section currently contains the allocated cluster for file XCOMMAND.BIN so you are right, the next file cluster to be allocated would start at EndProg.
However I spotted a bug since the boot block is set to 2 sectors per cluster. XCOMMAND.BIN uses 2 clusters ,so in fact it is 2k long not 1k
The real free space for XCOMMAND.BIN should have been -
EndProg: DS (2048-(EndProg-SignOnMsg)),'D' and YCOMMAND.BIN data would start after this.
Filling to the end of space is not essential. It does however provide a wayof checking if your load has worked as you expected it to and it avoids loading garbage from the disk.
Subject: [tatung_einstein] Re: The Experimental FAT Loader
Hi Phil,
A couple of questions;
If I wanted to read from a CF card plugged into my adaptor would I just have to re-write "ReadSectors:" to call the code to read a block from the CF instead of calling ZRBLK? (I'll obviously have to write the code first. I know there's no space for it, yet...)
Assuming the CF card contains the same data as created by your ASM file (i.e. formatted FAT16 with one file called XCOMMANDBIN), would I simply be able to add another file to the Root Directory like so;
Root: DM "XCOMMANDBIN" DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 FClust: DW $0000 ; points to first cluster of file (0) DB 0,0,0,0 DM "YCOMMANDBIN" DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 DW $0002 ; points to first cluster of file (1) DB 0,0,0,0 DS (512*8)-32,$E5
then add the data for the file after "SignOnMsg:" and "Endprog:", making sure to fill the space as "Endprog:" does.
Or do I also need to ad anything to "Fat1:"
I may be reading it wrong but I think that I could then change "CmdFileName:" to either run XCOMMANDBIN or YCOMMANDBIN
NOTE: I'm not planning on doing the above but want to know if I understand the concepts in your code. Like I've said before I'm no software expert.
If it helps you there is some information on LBA addressing for a CF card in my Compact Flash Access Guide in the files section of the site. Addressing an IDE adaptor would be the same
Regards, Geoff
No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.21.7/1329 - Release Date: 14/03/08 12:33
Hi Phil,
A couple of questions;
If I wanted to read from a CF card plugged into my adaptor would I
just have to re-write "ReadSectors:" to call the code to read a block
from the CF instead of calling ZRBLK? (I'll obviously have to write
the code first. I know there's no space for it, yet...)
Assuming the CF card contains the same data as created by your ASM
file (i.e. formatted FAT16 with one file called XCOMMANDBIN), would I
simply be able to add another file to the Root Directory like so;
Root: DM "XCOMMANDBIN"
DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
FClust: DW $0000 ; points to first cluster of file (0)
DB 0,0,0,0
DM "YCOMMANDBIN"
DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
DW $0002 ; points to first cluster of file (1)
DB 0,0,0,0
DS (512*8)-32,$E5
then add the data for the file after "SignOnMsg:" and "Endprog:",
making sure to fill the space as "Endprog:" does.
Or do I also need to ad anything to "Fat1:"
I may be reading it wrong but I think that I could then change
"CmdFileName:" to either run XCOMMANDBIN or YCOMMANDBIN
NOTE: I'm not planning on doing the above but want to know if I
understand the concepts in your code. Like I've said before I'm no
software expert.
If it helps you there is some information on LBA addressing for a CF
card in my Compact Flash Access Guide in the files section of the
site. Addressing an IDE adaptor would be the same
Regards,
Geoff
Hi Phil.
Great work.
The FAT loader sounds fantastic. It should help me get the Compact Flash
project back on
track.I should get time to play with it this evening. I'll be looking
into making up a batch
of adaptors once I can fully test my interface, the FAT loader should
help me do that.
I can't wait for the disassembley of the Xtal OS. It would be great to
be able to patch it to
work with large volume drives and CF cards. Then eventually aim for a
full IDE interface,
but that's some way off yet.
FAT compatibility would also open up the possibility of using USB ports.
Only for mass
storage devices, unless someone wants to write other drivers. With so
many devices showing
up as mass storage devices, everything from phones to thumb drives, to
digital cameras, and all
using FAT.
Taken to it's extreme it should be possible to connect a digital camera
through a USB port,
pull photos onto an Einstein IDE hard drive and send them over your LAN
with a serial-LAN
adaptor. ( I have some z80 tcp/ip code, but I'm more capable with the
hardware side of things)
Regards,
Geoff
Send Email
Offline 
