TIKI-100
TIKI-100
This was a bit obscure but very powerful machine from Norway.
It was quite interesting under several aspects, the current lib at the moment permits to run many of the graphics demos at a 1024x256 resolution. I'm taking this development session as an opportunity to revise a couple of bugs of the TS2068 High Resolution routines which were never fixed.
It was quite interesting under several aspects, the current lib at the moment permits to run many of the graphics demos at a 1024x256 resolution. I'm taking this development session as an opportunity to revise a couple of bugs of the TS2068 High Resolution routines which were never fixed.
Target support is now complete.
http://z88dk.org/wiki/doku.php?id=platform:tiki100
I set up a c lassic color cycling mandelbrot demo.. computation depth, palette, zoom window can be customized.
http://z88dk.org/wiki/doku.php?id=platform:tiki100
I set up a c lassic color cycling mandelbrot demo.. computation depth, palette, zoom window can be customized.
Impressive!
I have one of these machines, and it's incredible how little of the software released for it actually uses the graphics/sound to it's full extent. I'm doing some coding for it though; at the moment I'm making a simple game. It's gradually evolving, only game-over screen, highscore-list, credits screen and music data is missing. I'm coding in assembly, to get the most out of it in terms of speed.
With the graphics memory size and waitstates, the only way to really be fast enough for full 50Hz-speed with a lot going on is to use compiled sprites, monocolored background, and sprites that blank their own previous location when redrawn (a technique that also reduces flicker). In the worst-case you can loose a whooping 5 clocks to the VRAM synchronization cirquits per byte read or written, and 32K is a lot for a Z80 even without the waitstate cost!
I'd love to try the Maldelbrot demo on real hardware, though.
I have one of these machines, and it's incredible how little of the software released for it actually uses the graphics/sound to it's full extent. I'm doing some coding for it though; at the moment I'm making a simple game. It's gradually evolving, only game-over screen, highscore-list, credits screen and music data is missing. I'm coding in assembly, to get the most out of it in terms of speed.
With the graphics memory size and waitstates, the only way to really be fast enough for full 50Hz-speed with a lot going on is to use compiled sprites, monocolored background, and sprites that blank their own previous location when redrawn (a technique that also reduces flicker). In the worst-case you can loose a whooping 5 clocks to the VRAM synchronization cirquits per byte read or written, and 32K is a lot for a Z80 even without the waitstate cost!
I'd love to try the Maldelbrot demo on real hardware, though.
Last edited by FrodeM on Thu Oct 22, 2015 5:20 pm, edited 1 time in total.
Nothing to my knowledge was ever released on tape for this machine, and even the stock models had at least one standard 5.25" disk drive. In later machines the cirquits for tape were not even installed at all!
Otherwise, from what I read in the schematics, the Tape Input cirquit will lower the I/O pin B7 on the parallel port on both high and low sharp edges of the tape audio input signal. To restore the pin, lower I/O bit B6 for a brief time. Tape output is also just the inverted B6. Setting up for tape input would be as simple as set the PIO to trigger an interrupt on a falling edge of B7. The interrupt routine should certainly use a CTC channel to monitor the timing of how long since the last pulse, reset the CTC channel, and reset/set B6 to prepare for the next pulse. Setting up for tape output would be to configure a channel on the CTC, and use its interrupt to flip B6 at just the right intervals.
I'm unsure if any of the BASIC interperators supported tape, but both of them do support disk as well so tape was not really needed. In all honesty, the tape cirquit is, along with the second ROM socket, leftovers from a time when the developers of the machine considered producing a cheaper setup with no disk drives and BASIC in ROM. This configuration was to my knowledge never put in production, but I've seen an old ad announcing the idea (along with some other unrealized features, in particular differently colored chassises).
Otherwise, from what I read in the schematics, the Tape Input cirquit will lower the I/O pin B7 on the parallel port on both high and low sharp edges of the tape audio input signal. To restore the pin, lower I/O bit B6 for a brief time. Tape output is also just the inverted B6. Setting up for tape input would be as simple as set the PIO to trigger an interrupt on a falling edge of B7. The interrupt routine should certainly use a CTC channel to monitor the timing of how long since the last pulse, reset the CTC channel, and reset/set B6 to prepare for the next pulse. Setting up for tape output would be to configure a channel on the CTC, and use its interrupt to flip B6 at just the right intervals.
I'm unsure if any of the BASIC interperators supported tape, but both of them do support disk as well so tape was not really needed. In all honesty, the tape cirquit is, along with the second ROM socket, leftovers from a time when the developers of the machine considered producing a cheaper setup with no disk drives and BASIC in ROM. This configuration was to my knowledge never put in production, but I've seen an old ad announcing the idea (along with some other unrealized features, in particular differently colored chassises).
Yeah. I'd rather try to improve the video driver with a better way of doing the different graphics modes than to bitbang it all in.
I'll have a look at the source code and see what's there!
Sound support would be a nice thing as well, and it should be trivial to do if there are usable existing drivers for this already. It's just an AY-chip, same as the ZX Spectrum and Amstrad CPC but conveniently placed at IO address 0x16h (reg.select) and 0x17h (data). The I/O Data port defines at what physical line video start at, so this is very good for fast vertical scrolling! (Note: 0x0000h will always be upper left and 0x7FFFh will likewise always be lower right, no mather which line is set as the starting line. Changing the AY data register will only move the graphics already in video RAM.)
I'll have a look at the source code and see what's there!
Sound support would be a nice thing as well, and it should be trivial to do if there are usable existing drivers for this already. It's just an AY-chip, same as the ZX Spectrum and Amstrad CPC but conveniently placed at IO address 0x16h (reg.select) and 0x17h (data). The I/O Data port defines at what physical line video start at, so this is very good for fast vertical scrolling! (Note: 0x0000h will always be upper left and 0x7FFFh will likewise always be lower right, no mather which line is set as the starting line. Changing the AY data register will only move the graphics already in video RAM.)
The high resolution mode is very well supported (polygons, flood-fill, circles, relative and absolute drawing, sprites, "stencils", etc..).
You should be able to easily import the raster picture as monochrome sprites (i.e. converting the MS-DOS PrintMaster picture library with the sprite editor) or convert an SVG file with z80svg and use vector graphics in a flash
Since in this latter case the gray shades are converted to dithering patterns one could try to colorize the images in a similar way I did with the mandelbrot demo. Obviously a specific library would be more than appropriate.
The basic AY sound support is ready, you can try the "ex10.c" example in the "sound" folder, it will run.. As above, an high level AY sound function library is still missing but at this low-level layer permits the portability, so the new functions will work on all the supported targets at once.
You should be able to easily import the raster picture as monochrome sprites (i.e. converting the MS-DOS PrintMaster picture library with the sprite editor) or convert an SVG file with z80svg and use vector graphics in a flash
Since in this latter case the gray shades are converted to dithering patterns one could try to colorize the images in a similar way I did with the mandelbrot demo. Obviously a specific library would be more than appropriate.
The basic AY sound support is ready, you can try the "ex10.c" example in the "sound" folder, it will run.. As above, an high level AY sound function library is still missing but at this low-level layer permits the portability, so the new functions will work on all the supported targets at once.
I tried adding some calls for vertical scrolling, but I haven't been able to fully test it yet. I'm on a Windows machine so I've not even tried looking into what I need to do in order to pepare new libraries for the compiler.
I've also briefely changed a few things here and there to optimize a few of the existing routines. The Change palette routine did for example have the posibility for a rare glitch the first time it was run, if the palette data was being updated during a palette write.
The changed/new files are here: https://www.dropbox.com/s/s26cqxy1l3eivea/test.zip?dl=0
I've also briefely changed a few things here and there to optimize a few of the existing routines. The Change palette routine did for example have the posibility for a rare glitch the first time it was run, if the palette data was being updated during a palette write.
The changed/new files are here: https://www.dropbox.com/s/s26cqxy1l3eivea/test.zip?dl=0
Thankyou, I'll check them and update the CVS tree.. To build the libraries MinGW's Msys or CygWin are the easy way, IMHO, but a GNU Makefile should suffice (http://sourceforge.net/projects/unxutils/):
cd libsrc
make
move *.lib ..\z88dk\lib\clibs
cd libsrc
make
move *.lib ..\z88dk\lib\clibs
Here is some palette-setting code that should be slightly less broken than the last contribution.
Tried building the libraries myself, but MAKE bails out as it cannot find the compiler/assembler, even AFTER I added the bin directory to the PATH definition. Got the example C code to compile though.
Tried building the libraries myself, but MAKE bails out as it cannot find the compiler/assembler, even AFTER I added the bin directory to the PATH definition. Got the example C code to compile though.
Code: Select all
;
; Writes a single palette color from a palette of a given size,
; where the palette is looping through all 16 palette entries.
; Size 2, 4 and 16 makes sense, and no other values for size
; should be used.
;
;
; Input:
; A = Palette
; D = Position
; E = Size
;
.do_set
ld hl,$F04D
cpl ; complement color value
ld c,a
di
LD A,(hl) ; Make sure it's not writing to palette when the palette is updated, just in case
and $7F
ld (hl),a
OUT ($0C),A
ld b,$20 ; Wait a bit
.wait_loop2
djnz wait_loop2
ld a,c ; Store palette to be written
OUT ($14),A
ei
.palette_loop
DI
LD a,(hl) ; Prepare graphics port
and $70
or d ; palette position
ld c,a
or $80
OUT ($0C),A ; Enable writing to palette at end of this scanline
LD b,$20 ; wait for HBLANK to get the color copied in the requested palette position
.wait_loop
djnz wait_loop
ld a,c
LD (hl),a ; graphics port might have changed, so update corresponding data in RAM
OUT ($0C),A ; disable writes to the palette
EI
ld a,d ; move to next palette position for this color and palette size
add a,e
ld d,a
CP 16
JR C,palette_loop
RET
Last edited by FrodeM on Wed Nov 18, 2015 5:45 pm, edited 1 time in total.
It would be great to have you fully aboard
Just launch sccz80 zcc, and/or copt / appmake / z80asm at the command line to check your path.
Also remember the ZCC* variables: http://www.z88dk.org/wiki/doku.php?id=i ... _variables
Glad to hear you were able to build the examples, though.
I'll paste the updated ruotine ASAP.
Just launch sccz80 zcc, and/or copt / appmake / z80asm at the command line to check your path.
Also remember the ZCC* variables: http://www.z88dk.org/wiki/doku.php?id=i ... _variables
Glad to hear you were able to build the examples, though.
I'll paste the updated ruotine ASAP.
Things run fine from the command line, but it seems like the MAKE tool I'm using is either hardcoded to expect a bin directory somewhere else or has it's own PATH equivalent variable, or is buggy (it works if I copy the content of bin to every folder, though, but that's rather pointless). First library to fail compilation through MAKE from the libsrc directory is math\genmath if that sheds any more light on the matter.
Last edited by FrodeM on Fri Nov 20, 2015 1:08 am, edited 1 time in total.
Yey! Set up MSYS and now it compiles the source as well.
Also, I have made a sprite engine in assembly for a game I have been working on for quite some time, supporting up to 64 16x16 pixel sprites in the foreground, over a 256x256 background divided into 16x16 tiles. This is designed to work with the Tiki-100, and it should be not that hard to implement as a library in z88dk. It has a separate draw routine, and curently I have implemented only one expecting compiled sprites. The generalized draw routine just gets a pointer to the sprite data, and the pixel X/Y location of the upper left corner of where to draw it.
Most challenging thing will be that the sprite engine must know three pointert to the draw routine, but the draw routine is an independent module and not a fixed part of the sprite engine. Right now I have calculated the absolute addresses of these three locations, and I just pass these into the sprite engine using EQUs. Given the dynamic nature of the compiler, this will not work for a library. The draw routine also has to be above 0x8000h, which I will have to do some reaearch finding out how to ensure.
Other than that, implementing this as a C library should be pretty straightforwards.
Also, I have made a sprite engine in assembly for a game I have been working on for quite some time, supporting up to 64 16x16 pixel sprites in the foreground, over a 256x256 background divided into 16x16 tiles. This is designed to work with the Tiki-100, and it should be not that hard to implement as a library in z88dk. It has a separate draw routine, and curently I have implemented only one expecting compiled sprites. The generalized draw routine just gets a pointer to the sprite data, and the pixel X/Y location of the upper left corner of where to draw it.
Most challenging thing will be that the sprite engine must know three pointert to the draw routine, but the draw routine is an independent module and not a fixed part of the sprite engine. Right now I have calculated the absolute addresses of these three locations, and I just pass these into the sprite engine using EQUs. Given the dynamic nature of the compiler, this will not work for a library. The draw routine also has to be above 0x8000h, which I will have to do some reaearch finding out how to ensure.
Other than that, implementing this as a C library should be pretty straightforwards.
Last edited by FrodeM on Sat Nov 21, 2015 3:09 am, edited 1 time in total.
Is it not possible just to export those values with "PUBLIC" and import them where you need them with "EXTERN"? The library will be stored as a relocatable blob. If it needs to be above a certain or even at a specific address or alignment you can place it in a section holding that ORG.FrodeM wrote:Most challenging thing will be that the sprite engine must know three pointert to the draw routine, but the draw routine is an independent module and not a fixed part of the sprite engine. Right now I have calculated the absolute addresses of these three locations, and I just pass these into the sprite engine using EQUs. Given the dynamic nature of the compiler, this will not work for a library.
You can create a section to hold code at address 0x8000. At the end of the CRT you could probably do something like this:The draw routine also has to be above 0x8000h, which I will have to do some reaearch finding out how to ensure.
Code: Select all
....
SECTION HIGHMEM
org 32768
;; end of file
Code: Select all
section HIGHMEM
PUBLIC drawspr
drawspr:
....
There isn't any way to say, place HIGHMEM at address 32768 but only if the rest of the program (which presumably starts at 0x100) isn't large enough such that HIGHMEM can just be appended. That information is not available at assembly time. What is done in the new c lib is that ORG is changed to something user-definable via a pragma in the C source and a special value (0 maybe) can be taken to mean append the section (to do that just eliminate the ORG). So there has to be some human input to inform the linker that the program is big enough that the HIGHMEM section should just append to the rest of the code.
There might be some time since the last time I was around here, but in the mean time I have become a lot better at C. In the case of the Tiki-100, I also managed to find an obscure glitch that may happen on real hardware when changing the palette...
If bit 7 is set at the same time as the palette index is updated, an update might trigger with the old index because the write-palette signal has shorter hardware propagation-delay than the index. This only happens if the write-signal hits at one particular point in the horizontal trace cycle, so when it happens it's one of those things that can be really hard to both reproduce and wrap your head around. This is a hardware glitch, and literally none of the emulators will properly emulate this in any way. What this means for the library responsible for updating palette, is that the index needs to be set with a separate out-instruction before bit 7 is set.
If bit 7 is set at the same time as the palette index is updated, an update might trigger with the old index because the write-palette signal has shorter hardware propagation-delay than the index. This only happens if the write-signal hits at one particular point in the horizontal trace cycle, so when it happens it's one of those things that can be really hard to both reproduce and wrap your head around. This is a hardware glitch, and literally none of the emulators will properly emulate this in any way. What this means for the library responsible for updating palette, is that the index needs to be set with a separate out-instruction before bit 7 is set.
Welcome back!
Would you mind providing an update to the gr_setpalette() function here: https://github.com/z88dk/z88dk/blob/mas ... alette.asm - since you have the hardware you'll be able to verify that it's correct!
Would you mind providing an update to the gr_setpalette() function here: https://github.com/z88dk/z88dk/blob/mas ... alette.asm - since you have the hardware you'll be able to verify that it's correct!