A1000 prototype found (velvet)

[pandy71]

Originally Posted by ovale

Yes, who knows... anyway I doubt commodore did a spin of the chips in Yxx before RGB.

RGB or YPbPr (YUV) is more related to DAC design not chipset - even today RGB can be used as YUV (software related - put in color registers values for YPbPr) - nowadays you can hook to RGB a YPbPr input directly and code colors in software (not sure if this approach was not used by DCTV as DCTV is one big mystery - i can't find any detail how DCTV code video).

[ovale]

Yes. I was not clear.
With my comment I meant that I doubt commodore ever made the chip set as originally designed: yuv and with composite signal generation builtin. http://elwoodb.free.fr/Amiga/Jay.txt
It is actually fascinating to think that it would have been possible to have an Amiga with software selectable RGB/yuv mode.

[pandy71]

Originally Posted by ovale

Yes. I was not clear.
With my comment I meant that I doubt commodore ever made the chip set as originally designed: yuv and with composite signal generation builtin. http://elwoodb.free.fr/Amiga/Jay.txt
It is actually fascinating to think that it would have been possible to have an Amiga with software selectable RGB/yuv mode.

Yes, i know however seem that HAM should be in YUV mode with RGB output (i.e. YUV color space conversion on silicone).

Currently i investigating new vidiot capable to do regular RGB + YPbPr directly (same Amiga output as usual, sync on green etc) with digital control and perhaps some uC (XMOS?) on board to do extra things.
(To be honest it is quite tempting to place 3x32kB 8bit SRAM chips from old PC cache to have huge CLUT - controlling this from Copper/CPU and for example XMOS uC may be a nice thing - AGA already have similar feature and allow to put CLUT index in digital way).

[Paul_s]

Originally Posted by mark_k

The wire-wrapped breadboards are not, as far as I know, from the same stage of development as the black-box developer system.

They appeared in the same photos, sure. Maybe someone who used to work for Amiga exhibited both units at a computer show or user group etc.

Looks like the 'black box' prototype is the hub for the breadboard custom chips (I can't see any custom chips on the motherboard?)

edit: Yes, according to the text file 'ovale' posted above;

"In 1983 we made a motherboard for the breads to be plugged in, took this to
the CES show and we showed some little demos to selected people away from the
main floor. At the show itself, they wrote the bouncing ball demo and this
blew people away. They couldn't believe that all this wiring was going to be
three chips. The booming noise of the ball was Bob Parasseau hitting a foam
baseball bat against our garage door. It was sampled on an Apple ][ and the
data massaged into Amiga samples.CES was really important to us as we were
getting short of money and the response from that show really lifted the
team. We were still short of money and several re-mortgages later we managed
to keep up with the payroll. It's amazing how much it costs to pay 15 or 20
people!"

So that 'black box' prototype is from the 1983 CES show.

[Toni Wilen]

Explanation for "Copper not draining" serial debug message (that does not appear in emulation, for obvious reasons): Copper is not working.

"Dancing April Fool's GFXLIB" creates single-move copper list that should clear copper dma bit in DMACON. If bit does not clear after short CPU delay, "Copper not draining" is written to serial port, GFXLIB init is aborted, screen stays black (instead of showing green on black garbage..)

Probably not the only chip bug in prototype chips.

[mark_k]

Originally Posted by Paul_s

Looks like the 'black box' prototype is the hub for the breadboard custom chips (I can't see any custom chips on the motherboard?)

edit: Yes, according to the text file 'ovale' posted above;

"In 1983 we made a motherboard for the breads to be plugged in, took this to the CES show
..."

So that 'black box' prototype is from the 1983 CES show.

No, the black box unit is definitely much later than that. And it does have custom chips on its motherboard. Look at this pic. Date code on the MOS 6526 is 1884 (week 18 of 1984). The latest chip date code I can see in that pic is 8445 (on the 74HC112 to the left and slightly below the Portia chip). So at the earliest, that unit was made in late 1984.

The pic here shows the Portia chip (later known as Paula) at the bottom centre. "4703" is written on it. That chip looks to be on some kind of "kludge board", that board plugging into the socket on the motherboard. That may obscure another of the custom chips which could be plugged directly into the motherboard. Another board with what looks like the mouse port connectors on (lower right of the above pic) could obscure another custom chip.

The serial number label on the side says
COMMODORE-AMIGA
DEVELOPMENT SYSTEM
SERIAL NO. D-116

[pandy71]

Originally Posted by Toni Wilen

Explanation for "Copper not draining" serial debug message (that does not appear in emulation, for obvious reasons): Copper is not working.

"Dancing April Fool's GFXLIB" creates single-move copper list that should clear copper dma bit in DMACON. If bit does not clear after short CPU delay, "Copper not draining" is written to serial port, GFXLIB init is aborted, screen stays black (instead of showing green on black garbage..)

Probably not the only chip bug in prototype chips.

Paula DPLL data separator also not works (external FDC9216B used to perform data separation and clock recovery).

[Paul_s]

Originally Posted by mark_k

No, the black box unit is definitely much later than that. And it does have custom chips on its motherboard. Look at this pic. Date code on the MOS 6526 is 1884 (week 18 of 1984). The latest chip date code I can see in that pic is 8445 (on the 74HC112 to the left and slightly below the Portia chip). So at the earliest, that unit was made in late 1984.

The pic here shows the Portia chip (later known as Paula) at the bottom centre. "4703" is written on it. That chip looks to be on some kind of "kludge board", that board plugging into the socket on the motherboard. That may obscure another of the custom chips which could be plugged directly into the motherboard. Another board with what looks like the mouse port connectors on (lower right of the above pic) could obscure another custom chip.

The serial number label on the side says
COMMODORE-AMIGA
DEVELOPMENT SYSTEM
SERIAL NO. D-116

Yes, you're right! I'm going blind

I did some searching on Lorraine and found this page...

http://www.floodgap.com/retrobits/ck.../lorraine.html

That explains it then and that the picture of the breadboards/developer system were some kind of showcase to show what they had developed (not physical linked to one another).. ah, makes sense now.

edit: that photo of the breadboard/developer system were taken in 2003 - Dale Luck owns those apparently.

[ovale]

Originally Posted by pandy71

Currently i investigating new vidiot capable to do regular RGB + YPbPr directly (same Amiga output as usual, sync on green etc) with digital control and perhaps some uC (XMOS?) on board to do extra things.
(To be honest it is quite tempting to place 3x32kB 8bit SRAM chips from old PC cache to have huge CLUT - controlling this from Copper/CPU and for example XMOS uC may be a nice thing - AGA already have similar feature and allow to put CLUT index in digital way).

This is really interesting. I had a similar idea but I have not the skills or time. The problem to solve was how to write on this clut without additional address bus. A gpio or some magic color sequence switches on/off the clut in write mode. At that point the RGB data are interpreted as address, value touples.
The drawback is that clut can be changed only on the vblank.
A new vidiot savant could also transform halfbright mode in a real 64 colors mode, and as you said perform yuv to RGB conversion for a yuv ham mode.
Please do it

[pandy71]

Originally Posted by ovale

This is really interesting. I had a similar idea but I have not the skills or time. The problem to solve was how to write on this clut without additional address bus. A gpio or some magic color sequence switches on/off the clut in write mode. At that point the RGB data are interpreted as address, value touples.
The drawback is that clut can be changed only on the vblank.
A new vidiot savant could also transform halfbright mode in a real 64 colors mode, and as you said perform yuv to RGB conversion for a yuv ham mode.
Please do it

YUV<>RGB can be made in analog, programming CLUT content can be done on multiple ways, first you can use genlock signal with colors to store data in CLUT (ZD zero detect signal is active on OCS for Color 00 but in ECS it can be active for any signal so... but there is few other ways - like HAM-E, having XMOS CPU on board - 3E/$ cost - simplest 400MIPS with 4 slices give some flexibility - interpolating Copper chunky for example, CLUT switching etc)
Going slightly further and accessing Denise (RGA + other signals) gives lot of possibilities.

[Toni Wilen]

Originally Posted by pandy71

Paula DPLL data separator also not works (external FDC9216B used to perform data separation and clock recovery).

Perhaps this explains why Kickstart driver didn't use Paula's WORDSYNC mode for disk syncronization until KS1.4+: It didn't exist or was broken.

It may have been late Paula revision feature and they didn't want (and/or have time) to modify already feature complete and fully tested trackdisk.device code.

[Toni Wilen]

Another hardware difference found: Both CIA chips generate interrupt level 2. (CIA-A = level 2 and CIA-B = level 6 in production hardware)

Originally Posted by Toni Wilen

Unfortunately it isn't that simple.

Disk CIA pins seem to be differently wired. No one knows what kind of disk format it uses (it has no dos and no dos filesystem in rom). No one has floppies that originally came with it.

It only shows some green garbage on screen (second copper list contains garbage, first copper list is same as in later official roms). Real hardware shows same corruption.

Lots of unknowns.

It writes some debug info to serial port:

AMIGA ROM Operating System and Libraries.
Copyright 1984 by Commodore Amiga, Inc..

exec Version 23.93 (Tue Feb 12 11:53:20 PST 1985).
.
Dancing April Fool's GFXLIB 24.20 Apr 1,1985.
timer Version 23.207 (Thu Mar 7 19:38:02 PST 1985)..
TrackDiscDriver/Init: running on a Paula..
TrackDiscDriver Version 23.285 (Thu Mar 7 19:48:54 PST 1985)..
graphics vector nop.
graphics vector nop.
audio Ver 24.3  (Thu Mar 7 17:25:04 PST 1985)..
..
resources: CIA:0x15D0 disk.resource:0x1618 ..
devices: timer:0x1B6A TrackDiscDriver:0x1CBA Keyboard:0x1EBA GamePort:0x2020 Console:0x23B8 ..
libraries: exec:0x1282 graphics:0x1888 math:0x1AEC Utility:0x1E2A input.library: 0x230A audio:0x39B4 debug:0x3B2C ..

(btw, it is "velvet", not "verve")

Hi Toni,

very interesting thread!

Does the garbled screen look like this ?


This is a screenshot from an Amiga Velvet, ROM v24.61 with the serial number D-597.


I have never tried to connect this Amiga to a serial terminal.

Frank

[mark_k]

Aha, so someone else has one of these early units.

Would you be able to dump its Kickstart ROMs? It might in theory be possible to dump them using software if you don't want to risk damaging the chips.

In the mean time, write the attached ADF to disk and try booting your Velvet unit with it. Does it boot? You should see multi-coloured stripes if it does.

[Toni Wilen]

Originally Posted by NGFrankW

Does the garbled screen look like this ?

Yeah, black background and semi-random green garbage.

I have never tried to connect this Amiga to a serial terminal.

It is time to do it!

[JimDrew]

Originally Posted by pandy71

Paula DPLL data separator also not works (external FDC9216B used to perform data separation and clock recovery).

Ah... so this was one of the machines that was used to develop CBM's Paula patent. I know the original data separator logic was external to Paula, and then was later combined into the final rev chip, along with the other goodies (sound, DMA channels, etc.)

[mcbone]

Originally Posted by ovale

http://scacom.bplaced.net/Collection/velvet/velveten.php

http://scacom.bplaced.net/Collection...t/velveten.php

[mark_k]

A few ideas for how to dump the ROM data without physically removing and reading the EPROM chips:

- Output ROM data over the serial port, capture the data on your PC. Maybe the built-in serial monitor can be used for that, in which case no need for a working floppy drive.

- Write a small program to show a graphical representation of ROM data. Capture Amiga video output and process on PC to extract the data. (Similar principle to those old video backup system products, except simpler.)

- Write a small program to write the ROM data to floppy disk. I might have a go at doing that myself...

[mark_k]

Okay, here's that Velvet ROM-dumping program!

Instructions:
Write the ADF to a disk. Leave it write-enabled.
Power on Velvet system, insert the disk. Press Ctrl-Amiga-Amiga to reset.
Initially the screen will be yellow for a couple of seconds. As ROM data is written to the disk it flashes black/white. When finished the screen goes green. If there is a write error screen will go red.

Not tested on real hardware, but seems to work in WinUAE.

Edit to add: The 512KB at $F80000 is written to disk starting at track 1 side 0 (so offset 11264 in the ADF file).
Edit 2: if you accidentally boot with the disk write-protected the screen will go red, but I forgot to turn the drive motor off in that case. You'll probably want to reset then quickly remove the disk instead of removing it with the motor spinning.

[NLS]

Sorry for waking up the dead, but was there any progress with that ever?