TIKI-100

Discussion about other targets
Post Reply
stefano
Well known member
Posts: 1534
Joined: Mon Jul 16, 2007 7:39 pm

TIKI-100

Post by stefano »

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.
stefano
Well known member
Posts: 1534
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Monochrome graphics support is now fairly complete: putsprite, stencils and fill are supported :)
I also fixed the HR draw function, which was faulty also on the TS2068.
stefano
Well known member
Posts: 1534
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

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.
FrodeM
New member
Posts: 9
Joined: Thu Oct 22, 2015 4:59 pm

Post by FrodeM »

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.
Last edited by FrodeM on Thu Oct 22, 2015 5:20 pm, edited 1 time in total.
stefano
Well known member
Posts: 1534
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Good to hear someone else is making that little gem shine properly :)
There are several z88dk demos able to run on it now.. you might like "globe.c", in example.
If you try something I'd love to have a picture of the real machine running.
stefano
Well known member
Posts: 1534
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Forgot to say: if you wish to extend the TIKI-100 library with target specific functions, you're welcome.. we will add your code in the z88dk project tree.
I'd also like to work on a tape format converter if somebody provides sufficient information (docs, a sample wav file, etc..)
FrodeM
New member
Posts: 9
Joined: Thu Oct 22, 2015 4:59 pm

Post by FrodeM »

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).
stefano
Well known member
Posts: 1534
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Good, I missed that information.
If any model is able to read disks then we'll save our time for something else :)
FrodeM
New member
Posts: 9
Joined: Thu Oct 22, 2015 4:59 pm

Post by FrodeM »

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.)
stefano
Well known member
Posts: 1534
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

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.
stefano
Well known member
Posts: 1534
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Sorry ! It is named "ex12.c", actually..
FrodeM
New member
Posts: 9
Joined: Thu Oct 22, 2015 4:59 pm

Post by FrodeM »

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
stefano
Well known member
Posts: 1534
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

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
FrodeM
New member
Posts: 9
Joined: Thu Oct 22, 2015 4:59 pm

Post by FrodeM »

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.

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.
stefano
Well known member
Posts: 1534
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

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.
FrodeM
New member
Posts: 9
Joined: Thu Oct 22, 2015 4:59 pm

Post by FrodeM »

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.
stefano
Well known member
Posts: 1534
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

I'm currently using the MinGW's MSYS env. It does the job, even if it is slower than a native linux box ;)
FrodeM
New member
Posts: 9
Joined: Thu Oct 22, 2015 4:59 pm

Post by FrodeM »

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.
Last edited by FrodeM on Sat Nov 21, 2015 3:09 am, edited 1 time in total.
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

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.
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.
The draw routine also has to be above 0x8000h, which I will have to do some reaearch finding out how to ensure.
You can create a section to hold code at address 0x8000. At the end of the CRT you could probably do something like this:

Code: Select all

....

SECTION HIGHMEM
org 32768
;; end of file
Code that has to be above 32768 can be placed in that section:

Code: Select all

section HIGHMEM

PUBLIC drawspr

drawspr:
....
When you compile, if there is anything in that HIGHMEM section you will get a second binary as output. The two output files might be "prog.bin" and "prog_HIGHMEM.bin", eg. Then you would have to load "prog_HIGHMEM.bin" separately into memory at address 32768.


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.
FrodeM
New member
Posts: 9
Joined: Thu Oct 22, 2015 4:59 pm

Post by FrodeM »

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.
User avatar
dom
Well known member
Posts: 1194
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

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!
FrodeM
New member
Posts: 9
Joined: Thu Oct 22, 2015 4:59 pm

Post by FrodeM »

I added the IO steps I use in my own libraries to prevent the race-condition. Check it out in the pull-request.

In addition, I also fixed some off-by-one ldirs, as well as doing an attempt at making the code formatting somewhat consistent at least.
Post Reply