Cromemco dazzler replica project

[daver2]

What cards have you got in the N*?

The default configuration for the standard I/O motherboard N* devices are for I/O ports between 0 and 7. These should be away from the default $0E and $0F for the Dazzler.

If I remember correctly, the N* disk controller lives in memory space ($E8xx, $E9xx, $EAxx and $EBxx).

So (unless you have any other cards installed) I can't see where any clash lives.

Dave

 

[Gary C]

Nope, neither can I. Running a memory check only shows the boot ROM at $E000 and the Disk Controller.

I'm more thinking about running the GDEMO.COM from previous posts, would that work ? or would I need to recompile for the N*. Running GDEMO does display the intro on the terminal but just gives various flashing lines on the Dazzler and noticeably doesn't respond to CTRL-S etc

 

[Gary C]

Cant seem to get kscope compiled

A>asm test
CP/M ASSEMBLER - VER 2.0
S TOP@ST EQU 100H
S VID@BF EQU 200H
S DAZ@A EQU 0EH ; Dazzler Address Port Address
S DAZ@ON EQU 80H ; On/Off Bit
S DAZ@M EQU 0FH ; Dazzler Address Port Address
S DAZ@HR EQU 40h ; High Resolution (1)
S DAZ@ML EQU 20h ; Memory Size 512 Bytes (0) or 2 KiB (1)
S DAZ@CO EQU 10h ; Colour (1) or B&W (0)
S DAZ@S EQU 0EH ; Dazzler Synchronization Port Address
S DAZ@SL EQU 40h ; Line Synchronisation
S DAZ@SF EQU 40h ; Frame Synchronisation
E0000 310000 LXI SP,TOP@ST ; Set Top of Stack to 100h
E0003 3E00 MVI A,DAZ@ON+(.HIGH.VID@BF/2) ; Enable Dazzler and set the video buffer start to 0200h (=081h
E0005 D300 OUT DAZ@A ; Send to address port
E0007 3E00 MVI A,DAZ@ML+DAZ@CO ; (=30h)
E0009 D300 OUT DAZ@M ; Send to mode port
S ; B = X coordinate * 8 (!)
S ; C = Y coordinate * 8 (!)
007F
000H USE FACTOR
END OF ASSEMBLY

runs through with lots of comments then trying to load it gives the error ERROR: INVERTED LOAD ADDRESS, LOAD ADDRESS 0000

 

[daver2]

I can't see why GDEMO would not run on the N* off the top of my head.

It may be that the CP/M assembler you are using (or the KSCOPE source) uses / doesn't like the '@' character in a symbol.

Dave

 

[Gary C]

Yes, it does seem it doesnt like the @

But I wonder, I used PCGET to transfer and I have just noticed that XMODEM transfers are glitching a bit. Wonder if it got corrupted. Will try it again

 

[Gary C]

My intention then is to enter a very simple program from the monitor to check the operation of the system.

Have knocked up some code to draw a diagonal line in the first 8th of the screen which I will try this afternoon and have stripped out the Hex for the Op codes in the kaleidoscope rather than assemble it.

but Dave or anyone else have any really simple test programs ?

 

[Hugo Holden]

My intention then is to enter a very simple program from the monitor to check the operation of the system.

Have knocked up some code to draw a diagonal line in the first 8th of the screen which I will try this afternoon and have stripped out the Hex for the Op codes in the kaleidoscope rather than assemble it.

but Dave or anyone else have any really simple test programs ?

What about the K scope program, is that working ? Its a good test. And what does the screen display with just random memory bytes. You can also enter some bytes into the memory area the Dazzler is "scanning" and check the effect too.

 

[daver2]

I would try simple 'pokes' to memory with different coloured pixels. Start off with a low resolution, colour screen. In this mode, the memory layout is quite simple.

Dave

 

[Gary C]

I can turn the Dazzler on and set the modes. If I then do a fill of memory, I can see blocks of the screen fill, FF fills it solid in white, and coloured patterns with other values (with the right mode set of course).
If I do simple pokes I can see individual screen elements change, so it looks as if its working.

GDEMO puts the intro on the terminal and starts the Dazzler with a garbage screen then cycles colours, then starts to blink with flashes of garbage lines.

I have now got KSCOPE in Hex values so I hope to use the Program mode of the Vector Graphics Monitor to put it in memory (from $0000 I believe) then try to run it and I have also written a VERY simple program in Hex values to draw a diagonal line in the top 8th of the screen memory.

I have only just got my N* up and running so I am not familiar with it and not certain its totally error free either but it does seem to work.

 

[daver2]

Bells are ringing...

What software are you running? Presumably CP/M?

The GDEMO program calls the graphics subroutine INITG.

INITG uses the H register to locate where (in memory) the Dazzler buffers will be allocated.

If H is 0, INITG allocates the highest 4K block of RAM (below CDOS) for the Dazzler buffers.

If H is not 0, INITG allocates the lowest 4K block of RAM above the program. In this case, GRAPHZ80.REL ***MUST*** be linked LAST.

In the GDEMO program, HL is initialised to 0 before calling INITG, so the highest 4K block of RAM is allocated for the Dazzler buffers.

Three things:

1. Is the high memory in static or dynamic memory?
2. Is this memory used by other things I wonder?
3. INITG uses some 'voodoo magic and assumptions' related to CDOS to find the highest usable memory location. This magic may break if not using CDOS - or something that works with the equivalent magic mathematics.

Perhaps change HL (in particular H) to a non-zero value in the source code before calling INITG and ensure that GRAPHZ80.REL is linked after GDEMO.

Dave

 

[daver2]

The voodoo magic (if H is 0) is:

        ORG     $04A9
      
L04A9:  LD      A,($0007)           ; HIGH BYTE OF CDOS ENTRY POINT.
L04AC:  SUB     $11                 ; SOME MAGIC!!!
        AND     $FE                 ; MAKE SURE TO ALIGN TO A 512 BYTE MEMORY BOUNDARY.
        LD      (VB1978),A          ; SAVE AWAY?
        LD      H,A                 ; RETURN THE COMPUTED SCREEN BUFFER ADDRESS.
        LD      L,0                 ; MAKE SURE THE LOW BYTE IS 0 (REMEMBER, 512 BYTE ALIGNED).
        JR      L04C8               ; CONTINUE... ($10).

My disassembly comments for INITG state that if H is 0 - then the voodoo magic kicks in. Otherwise, HL contains the starting address of the video buffer in RAM. However, some further mathematics is done on the HL value, and I haven't quite worked this out yet. So, it may not be good enough just to set H to a non-zero value and get away with it...

In the above, the CP/M jump at location 5 is examined. This is the entry point into CDOS to process the CDOS BDOS request. This jump occupies memory addresses 5, 6 and 7. Location 7 is read and used to compute the Dazzler buffer start address. The "SUB $11" is the implied amount of code/data ahead of the CDOS entry point that gives us the first free byte of memory. If this is NOT true (depending upon which version of CP/M you are using), you could be corrupting things - either GDEMO is corrupting CP/M or CP/M is using memory where the Dazzler buffers have been allocated.

Dave

 

[Gary C]

Step 1

From the Vector Graphics Monitor, I put the program below in at 0200, Video address 0000 to 01FF. When it is run, it as designed, draws a line from the top left to the bottom right of the top left 1/4 of the screen.

However, it also fills in a small line and part of the screen is continually blinking, suggesting something is writing to it. When I reset the machine and to an Out 0E 80 Out 0F 3F, it shows the same display with the blinking, but when I power off and on, then issue the same there is no blinking

So I am pretty happy my Dazzler is working correctly but I am having issues with my N*

Just moved the program up to 2000 with the screen memory starting at 4000 and it works ok. Probably need to have a good look at my memory card setups. I have two very similar types by IMS and two have ports for 'memory management'


.CPU z80

;Dazzler IO ports
ADDR_PORT EQU $0E
CTRL_PORT EQU $0F


.ORG $0200

;Set starting address and turn on Dazzler
LD A,%10000000
OUT (ADDR_port),A

;Set to Normal Resolution, 2K picture, colour with RGB
LD A,%00111111
OUT (CTRL_port),A


LD HL,$0000
LOOP:

LD A,%11110000
LD (HL),A
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
LD A,%00001111
LD (HL),A
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL
INC HL

LD A,h
CP $02
JP nz,LOOP

JP $E000 ;jump back to the monitor

 

[daver2]

Just thinking...

What debug monitor are you using?

Is there anything connected to the interrupt header (especially the NMI pin)?

If any interrupts are happening, and the program is not crashing, then this could be interesting...

The NMI interrupt is entered via low memory and the stack will be used (which is pointing where?).

Dave

 

[Gary C]

I'm using a port of the Vector Graphics Monitor from the Deramp website and have done the mod to the CPU card to include a boot rom.

Not sure about NMI, will look into it. The stack is whatever GDEMO set it to I suppose. What I think I need is a build of KSCOPE or GDEMO to run higher in memory with the dazzler higher too.

 

[daver2]

The stack is allocated at the end of the GDEMO program/data.

GDEMO requires an operating system (e.g. CP/M) to operate correctly.

Dave

 

[daver2]

I assume you are using the vector monitor to download and run your programs?

If so, what locations does the monitor use for internal data and stack?

Just thinking about whether the program you are downloading can get corrupt when it us being downloaded.

Dave

 

[Ansgar Kueckes]

Don't know whether is is of use for you, but I once wrote a program for my own testing (see https://github.com/akueckes/Cromemco-Dazzler-RevD/blob/main/dazzler utility 2.0.zip).

Everything it does also can be done manually within a good monitor program (or front panel switches with some patience), but sometimes it is more convenient to use. It is fully menue driven and runs on CP/M 2.2, also with 8080. You can switch the Dazzler on and off, change the DMA base address, change the Dazzler modes and parameters, load patterns from a file (test patterns included), fill memory areas or do some tweaking.

-Ansgar

 

[Gary C]

I need to do some testing

My simple program I just loaded as Hex from the monitor. The monitor puts its stack at BF00 BFFF so well away from the programming area.

I think I need to test my RAM cards out carefully as as far as I can see, I should not see activity on the screen when its pointed at 0000, but its odd that it doesn't appear until I have run a program. Might need to run a proper memory test

I imagine CDOS wont work on a N* ?

 

[daver2]

>>> I imagine CDOS wont work on a N* ?

Unlikely, without a Cromemco disk controller and TUART etc.

Dave

 

[Hugo Holden]

In my article while playing around making test patterns, I wrote the byte values over the image, its a useful quick reference, if you write/poke those bytes to memory locations as a test, to see what the Cromemco board should display.

Also the video screen's address location map for an image starting at 0200h is helpful, since they segemented it into the wacky 4 quadrants (which significantly helped with the K scope program I think) It messed with my mind trying to figure out where a byte at some address was physically located on the screen so I had to draw out the map like that to make the test patterns.