Hombre Amiga Chipset

[Toffee]

Dr Ed Hepler who worked on the next generation Amiga chipsets AAA and Hombre at Commodore has kindly sent me some documentation on Hombre.

I can't find these documents online:-

Hombre: Beyond Amiga (October 8th 1993)
Hombre Presentation Notes To Phillips (12th April 1994, 64 pages)

Are people interested in seeing them and if so where is a good place for them to be preserved online as a part of Amiga history ?

[Hombre40]

Hi Toffee, this is the same touya from Youtube, glad you asked it here.

I believe for a start uploading it in The Zone would be a good idea, provided Ed Hepler gives you the green light. We may want to send them to Dave Haynie, since his website is a good candidate.

In any case I think it's a good idea to disseminate the files as much as possible.

I don't believe anyone ever saw them, only the person who won the 2015 auction by Haynie (assuming they are the same).

[apex]

Please upload it to the zone, this is a good beginning.

[Locutus]

Please upload to the zone or just put online anywere else so someone else can do it.

On a related note have people ever submitted these kind of documents to BitSavers to be included there? BitSavers are the experts (and goldmine) of preserving computer history documentation.

[Toffee]

Dr Ed Hepler has said it's okay with him as long as it's not sold or edited and the proper acknowledgement is made.

I don't have permission to upload to the zone.

[DamienD]

Originally Posted by Toffee

I don't have permission to upload to the zone.

How do I get access to the zone?

[Toffee]

A few high level specifications from the documents (a few conflicts with Wikipedia).

2 chip system sub $40 cost (0.6 micron).

• CPU/Renderer 64 bit Chip (Nathaniel)
  • HP PA RISC (64 bit)
    • Operates using 50mhz clock (guess-timate) performance of 55 VAXMIPS.
    • Integer only
    • 5 stage pipeline
    • Instruction / Data cache
    • MMU
    • SFU instructions added
  • Audio
    
    • 12 AAA style 16 bit 44.1 khz CD quality channels
  • Copper
    
    • 64 bit
    • Move multiple
    • No horizontal waiting
    • Move, Wait and Jump instructions
  • Blitter
    
    • 64 bit
    • Regular blits, line draw, shaded fills and texture mapping (quads/fixed point)
    • Clipping
    • Shadow registers
    • Pixel addressed (Supports 8, 16 and 32 bit colour)
    • 3 sources
  • Memory Copier
    • Memory to memory copy/fill
    • Consider it an independent simple minded Blitter channel

• Video Chip (Natalie)
  
  • Horizontal resolutions 640, 800, 1024 and 1280 (no 320 ?)
  • Vertical up-to 1024
  • 8 bit palette, HAM8, 16 and 32 bit chunky colour modes (In 32 bit mode its 24 bit colour + 8 bit overlay)
  • 2 * 256 24 bit CLUTs
  • 4 playfields (each upto 8 bit, combined = 32 bit mode)
  • Each playfield can be scrolled, scaled and positioned
  • Hardware playfield scaling ranges from 0.5 to 16x
  • Architecture supports 16 sprite channels (only 8 implemented) with 8 bit colour and 128 pixels wide. Sprites can be scaled or repeated. (Later document seems to mostly drop sprites)

[Toffee]

There are 7 PDF files of which 4 are over the 20 meg limit (25 meg is the largest).

I've uploaded the first one.

[DamienD]

Hmmm, you could always do the following:

... WinRAR all PDFs into an archive but split into 19MB parts.
... Upload each part to The Zone!

[Toffee]

I just zipped the files > 20 meg.

All uploaded now !

[grond]

Originally Posted by Toffee

Horizontal resolutions 640, 800, 1024 and 1280 (no 320 ?) Hardware playfield scaling ranges from 0.5 to 16x

The way I understand the second feature quoted above you could use it to turn a horizontal physical resolution of 640 into a logical resolution of only 40 pixels wide. Thus, you could easily create a standard low-res resolution by scaling x2 and doubling lines with the copper. The specs sound very reasonable for the time and could have meant a continuation of the Amiga approach to graphics hardware without just doing the simple thing and going the boring PC gfx card way. Still a pity that it didn't happen...

[Toffee]

Nice idea I wonder if that was one of the use cases for hardware playfield scaling.

It's an interesting feature that's not been mentioned about Hombre before. It seems you get it for free as the entire playfield image is loaded into the line buffer for each line and then the display hardware can resize before being displayed.

I was wondering if you could adjust the scaling factor on each line using the Copper. Mind you are such tricks necessary when you have a 64 bit texture mapping Blitter ?!

[Toffee]

[grond]

Originally Posted by Toffee

Mind you are such tricks necessary when you have a 64 bit texture mapping Blitter ?!

Well, the scaling reduces the load the screen DMA puts on the graphics memory because one set of graphics data loaded in one memory access lasts for more physical output pixels. The same goes for blitting. If you blit into a lores playfield that is stored as hires, you will have to blit twice as much even though you only get a lores looking image as a result. Hence, scaling is a good feature for this generation of graphics hardware. Today where even phones can do truecolour FullHD with a finger in the nose it may not seem so anymore.

[grond]

Oh, and scaling is very much Amiga. It is just like super-hires, hires and lores in ECS and AGA Amigas are all dirived from the super-hires pixel clock. Scale factors from x0.5 to x16 are probably taking things a little too far but having more options than you need has never hurt anyone and probably was easy to provide in the hardware.

[spudje]

Just wondering. How detailed are the specs? Detailed enough to, let's say implement something in, e.g. a new Vampire core? Or is it, as some info goes, totally breaking backwards compatibility with ECS/OCS/AGA?

[Jope]

Originally Posted by spudje

Just wondering. How detailed are the specs? Detailed enough to, let's say implement something in, e.g. a new Vampire core? Or is it, as some info goes, totally breaking backwards compatibility with ECS/OCS/AGA?

This was not supposed to be compatible with the classic chipsets.

[Hombre40]

They are a pretty detailed high level description of the system. Totally breaking with the Amiga architecture, but some ideas are beefed up ideas from the Amiga, I'd say. The hardware 3D support basically amounts to the Blitter being able to blit a scaled image on the area to do texture mapping, that is, there's no hardware vertext transformation pipeline.

A nice addition is a DMA channel for a frame grabber, and sprites being capable of being programmed to fetch from the ram area where the framebuffer DMA puts the data it reads, to overlay a video-in window with the regular video data fetched from RAM.

Wondering if Hombre's copper and blitter are similar to the AAA parts.

[grond]

Originally Posted by Hombre40

sprites being capable of being programmed to fetch from the ram area where the framebuffer DMA puts the data it reads, to overlay a video-in window with the regular video data fetched from RAM.

Ah, overlay windows! Perhaps that's why there is such a large range of scaling factors?

[Toffee]

Why do you think a 'System Copier' was added when there is already a 64 bit Blitter with copy mode ?