1
0
mirror of https://github.com/hsoft/collapseos.git synced 2024-11-02 10:20:55 +11:00

Compare commits

..

No commits in common. "24e588019bdb198de828e175c318eeff66ef767e" and "be66d7b4a256fb54e341437d8e91410bc46231d2" have entirely different histories.

25 changed files with 12 additions and 208 deletions

View File

@ -8,8 +8,8 @@ MASTER INDEX
280 Z80 boot code 350 ACIA driver
370 SD Card driver 390 Inner core
420 Core words 480 AT28 Driver
490 TRS-80 Recipe 520 Fonts
550 TI-84+ Recipe
490 TRS-80 Recipe

View File

@ -10,7 +10,7 @@ MOD a b -- c a % b -> c
AND a b -- c a & b -> c
OR a b -- c a | b -> c
XOR a b -- c a ^ b -> c
LSHIFT a u -- c a << u -> c
RSHIFT a u -- c a >> u -> c
Shortcuts: 1+ 2+ 1- 2-

View File

@ -6,7 +6,7 @@
( A, spits an assembled byte, A,, spits an assembled word
Both increase PC. To debug, change C, to .X )
: A, C, ; : A,, SPLITB A, A, ;
: <<3 3 LSHIFT ; : <<4 4 LSHIFT ;
: <<3 8 * ; : <<4 16 * ;
( As a general rule, IX and IY are equivalent to spitting an
extra 0xdd / 0xfd and then spit the equivalent of HL )
: IX 0xdd A, HL ; : IY 0xfd A, HL ;

View File

@ -1 +1 @@
1 53 LOADR+
1 51 LOADR+

12
blk/334
View File

@ -1,12 +0,0 @@
CODE RSHIFT ( n u -- n )
BC POPqq, ( u )
HL POPqq, ( n )
chkPS,
B C LDrr,
B INCr, B DECr, IFNZ,
BEGIN,
H SRLr, L RRr,
DJNZ, AGAIN,
THEN,
HL PUSHqq,
;CODE

13
blk/335
View File

@ -1,13 +0,0 @@
CODE LSHIFT ( n u -- n )
BC POPqq, ( u )
HL POPqq, ( n )
chkPS,
B C LDrr,
B INCr, B DECr, IFNZ,
BEGIN,
L SLAr, H RLr,
DJNZ, AGAIN,
THEN,
HL PUSHqq,
;CODE

View File

@ -9,8 +9,8 @@
: SDCMDR7
_sdcSel
_cmd ( r )
_idle 8 LSHIFT _idle + ( r arg1 )
_idle 8 LSHIFT _idle + ( r arg1 arg2 )
_idle 256 * _idle + ( r arg1 )
_idle 256 * _idle + ( r arg1 arg2 )
_sdcDesel
;

View File

@ -10,6 +10,6 @@
SWAP 1+ ( crc a+1 )
LOOP
DROP ( crc1 )
_idle 8 LSHIFT _idle + ( crc2 )
_idle 256 * _idle + ( crc2 )
_wait DROP _sdcDesel
= NOT IF _err THEN ;

View File

@ -3,14 +3,14 @@
( 4 256b sectors per block, 10 sec per cyl, 40 cyl max )
10 /MOD ( sec cyl )
DUP 39 > IF _err THEN
8 LSHIFT + ( cylsec )
256 * + ( cylsec )
;
: FD@! ( wref blk -- )
1 @DCSTAT NOT IF _err THEN
2 LSHIFT ( 4 * -- wr sec )
4 * ( wr sec )
4 0 DO ( wr sec )
DUP I + _cylsec ( wr sec cs )
I 8 LSHIFT BLK( + ( wr sec cs addr )
I 256 * BLK( + ( wr sec cs addr )
1 ROT ROT ( wr sec drv cs addr )
4 PICK EXECUTE NOT IF _err THEN
LOOP 2DROP ;

13
blk/520
View File

@ -1,13 +0,0 @@
Fonts
Fonts are kept in "source" form in the following blocks and
then compiled to binary bitmasks by the following code. In
source form, fonts are a simple sequence of '.' and 'X'. '.'
means empty, 'X' means filled. Glyphs are entered one after the
other, starting at 0x21 and ending at 0x7e. To be space
efficient in blocks, we align glyphs horizontally in the blocks
to fit as many character as we can. For example, a 5x7 font
would mean that we would have 12x2 glyphs per block.
521 Font compiler 530 3x5 font
532 5x7 font 536 7x7 font

View File

@ -1,6 +0,0 @@
( Converts "dot-X" fonts to binary "glyph rows". One byte for
each row. In a 5x7 font, each glyph thus use 7 bytes.
Resulting bytes are aligned to the left of the byte.
Therefore, for a 5-bit wide char, "X.X.X" translates to
0b10101000. Left-aligned bytes are easier to work with when
compositing glyphs. )

16
blk/522
View File

@ -1,16 +0,0 @@
: _g ( given a top-left of dot-X in BLK(, spit 5 bin lines )
5 0 DO
0 3 0 DO ( a r )
2 *
OVER J 64 * I + + C@ 'X' = IF 1+ THEN
LOOP 32 * C, LOOP DROP ;
: _l ( spit a line of u glyphs )
( u ) 0 DO ( a )
DUP I 3 * + _g
LOOP DROP ;
: CPFNT3x5
0 , 0 , 0 C, ( space char )
530 LOAD BLK( 21 _l 192 + 21 _l 192 + 21 _l ( 63 )
531 LOAD BLK( 21 _l 192 + 10 _l ( 94! )
;

16
blk/530
View File

@ -1,16 +0,0 @@
.X.X.XX.X.XXX...X..X...XX...X...............X.X..X.XX.XX.X.XXXX
.X.X.XXXXXX...XX.X.X..X..X.XXX.X............XX.XXX...X..XX.XX..
.X........XX.X..X.....X..X..X.XXX...XXX....X.X.X.X..X.XX.XXXXX.
......XXXXX.X..X.X....X..X.X.X.X..X.......X..X.X.X.X....X..X..X
.X....X.X.X...X.XX.....XX........X......X.X...X.XXXXXXXX...XXX.
.XXXXXXXXXXX........X...X..XX..X..X.XX..XXXX.XXXXXX.XXX.XXXXXXX
X....XX.XX.X.X..X..X.XXX.X...XXXXX.XX.XX..X.XX..X..X..X.X.X...X
XXX.X.XXXXXX......X.......X.X.XXXXXXXX.X..X.XXX.XX.X.XXXX.X...X
X.XX..X.X..X.X..X..X.XXX.X....X..X.XX.XX..X.XX..X..X.XX.X.X...X
XXXX..XXXXX....X....X...X...X..XXX.XXX..XXXX.XXXX...XXX.XXXXXX.
X.XX..X.XXX.XXXXX.XXXXX..XXXXXX.XX.XX.XX.XX.XXXXXXXX..XXX.X....
XX.X..XXXX.XX.XX.XX.XX.XX...X.X.XX.XX.XX.XX.X..XX..X....XX.X...
X..X..XXXX.XX.XXX.X.XXX..X..X.X.XX.XXXX.X..X..X.X...X...X......
XX.X..X.XX.XX.XX..XXXX.X..X.X.X.XX.XXXXX.X.X.X..X....X..X......
X.XXXXX.XX.XXXXX...XXX.XXX..X.XXX.X.X.XX.X.X.XXXXXX..XXXX...XXX
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_

11
blk/531
View File

@ -1,11 +0,0 @@
X.....X.......X....XX...X...X...XX..XX.......................X.
.X.XX.X...XX..X.X.X...X.X........X.X.X.X.XXX..X.XX..XX.XX.XXXXX
.....XXX.X...XXX.XXX.X.XXX..X...XXX..X.XXXX.XX.XX.XX.XX..XX..X.
...XXXX.XX..X.XXX.X...XXX.X.X...XX.X.X.X.XX.XX.XXX..XXX....X.X.
...XXXXX..XX.XX.XXX..XX.X.X.X.XX.X.X.XXX.XX.X.X.X....XX..XX..XX
...................XX.X.XX.....................................
X.XX.XX.XX.XX.XXXX.X..X..X..XX
X.XX.XX.X.X..X..XXX...X...XXX.
X.XX.XXXX.X..X.XX..X..X..X....
XXX.X.X.XX.X.X.XXX.XX.X.XX....
`abcdefghijklmnopqrstuvwxyz{|}~

17
blk/532
View File

@ -1,17 +0,0 @@
...............................................................
...............................................................
...............................................................
...............................................................
...............................................................
...............................................................
...............................................................
...............................................................
...............................................................
...............................................................
...............................................................
...............................................................
...............................................................
...............................................................
...............................................................

View File

@ -1,6 +0,0 @@
TI-84+ Recipe
Support code for the TI-84+ recipe. Contains drivers for the
keyboard and LCD.
551 LCD

16
blk/551
View File

@ -1,16 +0,0 @@
TI-84+ LCD driver
Implement (emit) on TI-84+ (for now)'s LCD screen. Load with
"555 LOAD".
The screen is 96x64 pixels. The 64 rows are addressed directly
with CMD_ROW but columns are addressed in chunks of 6 or 8 bits
(there are two modes).
In 6-bit mode, there are 16 visible columns. In 8-bit mode,
there are 12.
Note that "X-increment" and "Y-increment" work in the opposite
way than what most people expect. Y moves left and right, X
moves up and down.
(cont.)

16
blk/552
View File

@ -1,16 +0,0 @@
# Z-Offset
This LCD has a "Z-Offset" parameter, allowing to offset rows on
the screen however we wish. This is handy because it allows us
to scroll more efficiently. Instead of having to copy the LCD
ram around at each linefeed (or instead of having to maintain
an in-memory buffer), we can use this feature.
The Z-Offet goes upwards, with wrapping. For example, if we
have an 8 pixels high line at row 0 and if our offset is 8,
that line will go up 8 pixels, wrapping itself to the bottom of
the screen.
The principle is this: The active line is always the bottom
one. Therefore, when active row is 0, Z is FNT_HEIGHT+1, when
row is 1, Z is (FNT_HEIGHT+1)*2, When row is 8, Z is 0. (cont.)

16
blk/553
View File

@ -1,16 +0,0 @@
# 6/8 bit columns and smaller fonts
If your glyphs, including padding, are 6 or 8 pixels wide,
you're in luck because pushing them to the LCD can be done in a
very efficient manner. Unfortunately, this makes the LCD
unsuitable for a Collapse OS shell: 6 pixels per glyph gives us
only 16 characters per line, which is hardly usable.
This is why we have this buffering system. How it works is that
we're always in 8-bit mode and we hold the whole area (8 pixels
wide by FNT_HEIGHT high) in memory. When we want to put a glyph
to screen, we first read the contents of that area, then add
our new glyph, offsetted and masked, to that buffer, then push
the buffer back to the LCD. If the glyph is split, move to the
next area and finish the job.
(cont.)

View File

@ -1,3 +0,0 @@
That being said, it's important to define clearly what CURX and
CURY variable mean. Those variable keep track of the current
position *in pixels*, in both axes.

16
blk/555
View File

@ -1,16 +0,0 @@
( Required config: TI_MEM )
: TI_MEM+ [ TI_MEM LITN ] + ;
: LCD_PORT_CMD 0x10 ;
: LCD_PORT_DATA 0x11 ;
: FNT_WIDTH 3 ;
: FNT_HEIGHT 5 ;
( Current Y position on the LCD, that is, where we're going to
spit our next glyph. )
: LCD_CURY 0 TI_MEM+ ;
: LCD_CURX 1 TI_MEM+ ;
( two pixel buffers that are 8 pixels wide (1b) by FNT_HEIGHT
pixels high. This is where we compose our resulting pixels
blocks when spitting a glyph. )
: LCD_BUF 2 TI_MEM+ ;
1 2 LOADR+

11
blk/556
View File

@ -1,11 +0,0 @@
: _wait ( Wait until the lcd is ready to receive a command )
( When 7th bit is cleared, we can send a new command )
BEGIN LCD_PORT_CMD PC@ 0x80 AND NOT UNTIL ;
: _cmd LCD_PORT_CMD PC! _wait ;
: _data! LCD_PORT_DATA PC! _wait ;
: _data@ LCD_PORT_DATA PC@ _wait ;
: LCDOFF 0x02 ( CMD_DISABLE ) _cmd ;
: _col! ( col -- )
0x20 ( CMD_COL ) + _cmd ;
: _row! ( row -- )
0x80 ( CMD_ROW ) + _cmd ;

View File

@ -1,3 +0,0 @@
( Load a "glyph line" from buffer, left part being in MSB and
right part being in LSB. )
: _gl@

View File

@ -1,5 +0,0 @@
: _glyph> ( a -- )
LCD_CURY C@ _row! LCD_CURX C@ 8 /MOD _col! ( a coff )
0x05 ( XINC ) _cmd _data@ DROP
FNT_HEIGHT 0 DO LOOP

Binary file not shown.