Re: [colorforth] CF05, Block 20 (USB), “free”
- Subject: Re: [colorforth] CF05, Block 20 (USB), “free”
- From: Nick Maroudas <alice@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 3 Dec 2008 14:56:36 +0200
Tutorial: USB - step 1
The USB blocks are 20 & 22 in CF05 and 82-86 in CF2a. I
use CF05.
The USB device hangs on the PCI bus (block 46 in CF05,
50 in CF2a).
A forth word 'device' has been predefined in the CFO5
core: given
the class number of a certain device, it returns the PCI
address.
For example a graphics device is class code 3 and usb is
c. So
'46 load' (load pci block)
'3000000 device' returns '80010000'
'c000000 device' >> '8000e800'
which are the pci addresses of the Invidia graphic and
Intel USB
devices on my PC.
Alternatively I could dump a list of devices by entering
the word
'k' >> '8000e800 27c88086' (among others)
To find the pci address of the usb io register, I first
tell 'dev'
that I want the usb device, then enter 'ok' thus
'8000e800 dev ! ok' (dumps all the usb
registers)
Cell 20 of the resultant dump tells me that usb io base
is 2080.
(By the way, Linux words 'lspci' and 'setpci' confirm
the
forth addresses above, though the address system is a
little
different. Linux returns 00:1d so multiply 1d by 800 to
get
e800 in the CF system).
So now I can move to the USB blocks, and try to
understand what
is going on there. Block 20 starts with macros 'p@'
and 'b!'
which are explained on block 21 as 'port fetch' and
'store EAX
in literal byte address' respectively. So we are going
to
fetch something from a usb port and store it somewhere
in memory.
Forth words begin with 'ad' explained as 'byte address
of usb
16 bit register'.
n>>n : ad 8000e820 pci -1 + or ;
Now I have learnt that e820 holds the base io register
number of
the usb device, and a previous tutorial explained the
word 'pci'
- it means fetch from a pci address. So 'ad' is going
to fetch
the uob io base 2080 from pci address e820, and 'or'
it with n.
The next word is 'u@' which explains itself, forth
style:
n>>n : u@ ad p@ ;
So we are going to fetch numbers from 16 bit usb
register base+n.
The next word 'regs' contains a '12 for ... -next'
which means
that it is going to poll 13 registers including zero or
base 2080.
The next word 'ok' does just that. (I prefer to
rename 'ok'
as 'ko' to prevent confusion with the 'ok' in block
46).
'ko' dumps 13 wordsize regs, from byte addresses 2080 to
2098.
I can confirm the value in any given reg n by 'n u@'
The dump suggests that registers 3 and 4 are continually
active,
as shown by continual flickering. Significantly, a
subsequent word
'frame' does fetch from one of these flickering
registers:
: frame ... 4 u@ ... ;
The CF word 'frame' is explained in block 21 as
"address of
first accessible frame; and the USB word 'frame' is
explained
in a USB Protocol Specification - for instance in
http://www.faculty.iu-bremen.de/birk/lectures/PC101-2003/14usb/FINAL%20VERSION/usb_protocol.html
So I have moved beyond instructions that get usb io via
pci bus,
and am now trying to understand the USB protocol proper:
a
polled bus with frames and packets.
A small step, but I hope to follow with step 2.
Caritas,
Nick
Quoting Nick Maroudas <alice@xxxxxxxxxxxxxxxxxxxxxxx>:
>... " Quoting Jason Kemp
>... " <jason.kemp@xxxxxxxxxxxxxxxx>:
>... "
>... " >... " Hi Nick,
>... " [snip]
>... " >... " I think it might not be a specific USB
>... " >... " point?it?s the command ?ok? below
>... " >... " (listing still right at bottom).
>... " >... "
>... " >... " ok show black screen white regs keyboard
>... " ; free
>... " >... " 67106904
>... " >... " 3fff800 free !
>... " >... "
>... " [snip]
>... " >... "
>... " >... " That 3fff800 is a bit smaller than
>... " 4000000,
>... " >... " which is 64MB. But why that
>... " >... " number? Is there a simple explanation
>... " of
>... " >... " colorForth?s memory map anywhere?
>... " >... "
>... " >... " There is the following in Josh Grams
>... " source (the
>... " >... " one I use):
>... " >... " ; 100000 dictionary
>... " >... " ; a0000 return stack (main)
>... " >... " ; 9f400 data stack
>... " >... " ; 9dc00 return stack (draw)
>... " >... " ; 9d000 data stack
>... " >... " ; 9b800 return stack (serve)
>... " >... " ; 9ac00 data stack
>... " >... " ; 99400 divider (bottom of rstack, top
>... " of
>... " >... " floppy buffer)
>... " >... " ; 94c00 floppy buffer
>... " >... " ; 92c00 forth dictionary addrs (room
>... " for 2048
>... " >... " entries)
>... " >... " ; 90c00 forth dictionary names
>... " >... " ; 7c00 BIOS loads boot sector here;
>... " we
>... " >... " immediately move it to 0
>... " >... " ; 4800 source
>... " >... " ; 3000 icons
>... " >... " ; 0 the colorforth kernel
>... " >... "
>... " >... " So this goes up to 100000h (1MB)
>... " >... "
>... " >... " I might be barking up entirely the wrong
>... " tree
>... " >... " though. Maybe it is a
>... " >... " peculiar USB?affected memory address.
>... " >... "
>... " >... " Thanks,
>... " >... " Jason
>... " >... "
>... "
>... " Nick here: Or "free" might be freeing some
>... " working
>... " space for usb? By analogy with CF's graphic
>... " screen
>... " memory, which tops at 2000000 (see
>... " GeneralGraphis.asm
>... " in Josh).
>... "
>... " Glad someone is trying to elucidate the usb in
>... " CF05;
>... " because there's a lot more of it waiting in
>... " CF2.
>... "
>... " Caritas,
>... "
>... " Nick
>... "
>... " ****
>... "
>... " We are but shaved monkeys - some of us with a
good grasp of technology.
- Guardian blogger"
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com
