Apple II VGA Video Generator Card Project

[Jorge Chamorro Bieling]

I was already thinking about modifying my videx to do that, and I may
try to do it someday...

..but reading what you the people at csa2 are saying this week, I've
seen that having a modified videx maybe a nice thing but is not *the
solution*.

So here is what I've been thinking about it this week.
May it be the way to go ?

"Apple II VGA Video Generator Card Project"
<http://homepage.mac.com/jorgechamorro/a2things/index.html>

What do you think ?

Regards,
--
Jorge Chamorro Bieling

[aiia...@gmail.com]

I added a link to your site on mine
(http://rich12345.tripod.com)

If you design the card using programmable
logic, extra (non compatible) video modes
could be added at any time.

perhaps put a mechanical switch on the
card that connects the PROGRAM pins
of the logic device to the address/data
bus. Re-Program the device (new program
loaded off disk), flip the switch (no slot addresses
taken by the card any longer), and you've
got new logic on your card..

I've been looking at VGA "drivers" in FPGA, and
it seems that it isn't difficult. Stretching the pixels
to fit the screen would be a matter of changing
timing. FPGA can handle the timing

lookup table for HGR:

for v=0 to 191
Get V address
bit=1
for H=0 to 279(+40)

get data at Vaddress,H
AND with BIT
display on screen (change timing to stretch pixels)
ROL BIT
if bit=8 then bit=1:next H
NEXT V

here is link to driving VGA with FPGA:

http://www.fpga4fun.com/PongGame.html

Rich

[aiia...@gmail.com]

oops

BIT=1

for v=0 to 191
Get V address

for H=0 to 279

for bitcount = 1 to 7

get data at Vaddress,H
AND with BIT
display on screen (change timing to stretch pixels)
ROL BIT

next bitcount
BIT=1
next h
next v

[aiia...@gmail.com]

http://www.mirrow.com/FPGApple/screenshots.html

http://www.mirrow.com/FPGApple/

He's got apple II video displaying on a VGA screen, perhaps
the code can be modified to work with dual port RAM in
a real apple II

Rich

[aiia...@gmail.com]

http://www.applefritter.com/blog/12920

Gary Becker, another person playing with
Apple II and programmable logic.

He's got the video portion working.

Rich

[Michael J. Mahon]

Jorge Chamorro Bieling wrote:
> I was already thinking about modifying my videx to do that, and I may
> try to do it someday...
>

> ...but reading what you the people at csa2 are saying this week, I've

> seen that having a modified videx maybe a nice thing but is not *the
> solution*.
>
> So here is what I've been thinking about it this week.
> May it be the way to go ?
>
> "Apple II VGA Video Generator Card Project"
> <http://homepage.mac.com/jorgechamorro/a2things/index.html>
>
> What do you think ?

Looks like a very practical approach.

-michael

Music synthesis for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."

[Bryan Parkoff]

"Jorge Chamorro Bieling" <bie...@terra.es> wrote in message
news:1hayiar.1guk4651d7lh1uN%bie...@terra.es...

I have read if I understand, but I want to give you my thought. They
claim to add incompatible video mode. Do you mean to add new softswitch for
VGA? If it is the issue, I would suggest to have 256 colors at 320x200
resolution. Total bytes are 64,000. You can divide it into 32,000. Main
memory will have 32,000 bytes and aux memory will have 32,000 bytes. Both
of them start at $2000 through $9D00.
The problem is that it takes too much memory which it does not have
enough memory for software to run. It may have approximately 16K available
in both main and aux memory. Then 16K in high RAM ($D000-$FFFF) are needed
to bring total up to 60KB in both main/aux memory.
I have been considering to use EGA instead of VGA. It would be only
32,000 bytes in aux memory from $2000 through $9D00.. It would be 16 colors
at 320x200 resolution. It gives enough memory in main memory for software
(from $800 through $BFFF) to run while it begins to draw pixel by pixel in
aux memory by transferring data from main memory to aux memory.
It can be forth try unless we have to find other way to add a new
softswitch to support video mode for EGA and VGA. Apple II can't add new
softswitches unless we should be able to modify softswitch logic on the
motherboard.
In other words, I understand that you may want to emulate NTSC into VGA
using existing Apple II's video modes.
Please provide what do you think?

Bryan Parkoff

[aiia...@gmail.com]

>Do you mean to add new softswitch for
>VGA? If it is the issue, I would suggest to have 256 colors at 320x200
>resolution. Total bytes are 64,000. You can divide it into 32,000. Main
>memory will have 32,000 bytes and aux memory will have 32,000 bytes. Both
>of them start at $2000 through $9D00

That is the idea.. New "softswitches" for **incompatible** video
modes.
Not a very useful thing (zero software available to take advantage of
it)
but it would be a fun project.

in your example above, 1 pixel = 256 colors (eight bits, 1 byte)

I'm going to get around to this project myself, eventually. I'd like
to hear of other resolutions / color schemes.

[Alex Freed]

Great minds think alike :))

I was going to mention that I already have Verilog that does a good job
of showing standard Apple video on a VGA screen. I didn't do the double
hires, but it is quite trivial to add.

So one simple way to do it is to put the smallest Spartan 3 or Altera
Cyclon FPGA on a card. It has everything: enough RAM for the frame
buffer, PLL to multiply the clock frequency and more than enough logic
to do the job. XC3S50-4VQ100C costs $10. That's the good part. The bad
part is that soldering such chips is beyond hobbyist technology. At
least for most people. So it has to be done professionally.

The beauty of the FPGA approach is that it is so flexible. You can
always add a new video mode or what have you at any time. The character
generator will also fit inside and can be re-programmed.

On the other hand if you have an FPGA, why stop at video generation when
I have fitted the whole Apple 2 into it? And who needs accelerator chips
if I can run my "6502" at 28 MHz clock? Probably even faster if needed.

Then again the VGA video card could be built with just TTL chips and
GALs or a CPLD. Easier to assemble but a lot more parts.

BTW there is no need for dual ported RAM: 500 nS out of every 1 mS 6502
does not acess the memory. That's how the normal Apple video works.
Using modern SRAM it is trivial to read 4 bytes in 500 nS (double scan
rate AND double hi-res or 80 columns).

I could make either a video for VGA or a whole FPGApple available
commercially if I new there was a market.

[Bryan Parkoff]

<aiia...@gmail.com> wrote in message
news:1140306684.2...@o13g2000cwo.googlegroups.com...

Hello,

Yes, it is correct because VGA requires 64,000 bytes which each byte is
256 colors while EGA requires only 32,000 bytes which each nibble is 16
colors. It is why I recommend EGA in aux memory. I am concerned that high
RAM ($D000 through $FFFF) in both main/aux memory will be set to read/write
only when Applesoft BASIC ROM and Monitor / AutoStart ROM are not needed (or
only 2-5 routines of monitor ROM are needed) otherwise you will have to
write your own routines to support cold-warm reboot routine only. No idea
to deal with keyboard routine unless you need it. It will be perfect for
software with its own routines for cold-warm reboot and keyboard routines to
run EGA and VGA memory when it does not need routines from Monitor ROM.
Does it make sense to take more memory space?

Bryan Parkoff

[Mark McDougall]

aiia...@gmail.com wrote:

> He's got apple II video displaying on a VGA screen, perhaps
> the code can be modified to work with dual port RAM in
> a real apple II

Hasn't everyone? ;)

<http://members.iinet.net.au/~msmcdoug/pace/Nanoboard/appleii_running.jpg>

Regards,

--
| Mark McDougall | "Electrical Engineers do it
| <http://members.iinet.net.au/~msmcdoug> | with less resistance!"

[Henry]

Hello Alex.

Could you please email me that section of the HDL code? If you do plan on
writing DHGR support, I wouldn't complain. ;-) Save us some work.
Soldering for us is also no problem either.

Email on this account is good. Thanks.

Henry S. Courbis
www.GSE-Reactive.com
Apple II Series Legacy Hardware - Come take a look at what we have to offer!

"Alex Freed" <al...@mirrow.com> wrote in message
news:g_SdnX3BcN0...@comcast.com...

[Kevin Greene]

Bryan Parkoff wrote:
>
> I have read if I understand, but I want to give you my thought. They
> claim to add incompatible video mode. Do you mean to add new softswitch for
> VGA? If it is the issue, I would suggest to have 256 colors at 320x200
> resolution. Total bytes are 64,000. You can divide it into 32,000. Main
> memory will have 32,000 bytes and aux memory will have 32,000 bytes. Both
> of them start at $2000 through $9D00.
> The problem is that it takes too much memory which it does not have
> enough memory for software to run. It may have approximately 16K available
> in both main and aux memory. Then 16K in high RAM ($D000-$FFFF) are needed
> to bring total up to 60KB in both main/aux memory.

You can just design the card itself with softswitches to bank switch in
just about how much memory you would like.

Also, this sort of card is similar to a LCD driver card I'm interested
in. Instead of generating VGA, you take the existing video memory and
use an LCD controller (I'm talking about raw LCD panels, not vga/ntsc
input) and fill its memory directly. LCD controllers are memory mapped
so they take care of displaying what's in there. The main problem is
finding a surplus panel that's reasonably priced, is color, and also
handles the resolution. You can find 320x240 and 640x480 panels that
are cheap but the docs are almost nonexistent or you have to drive them
directly without a premade controller (there appear to be a few popular
ones so making a card for one of these would support a whole class on
lcd panels). Once one of these works, an apple II laptop (a REAL one)
would be much easier...

[Michael J. Mahon]

Michael J. Mahon wrote:
> Jorge Chamorro Bieling wrote:
>
>> I was already thinking about modifying my videx to do that, and I may
>> try to do it someday...
>> ...but reading what you the people at csa2 are saying this week, I've
>> seen that having a modified videx maybe a nice thing but is not *the
>> solution*.
>>
>> So here is what I've been thinking about it this week.
>> May it be the way to go ?
>>
>> "Apple II VGA Video Generator Card Project"
>> <http://homepage.mac.com/jorgechamorro/a2things/index.html>
>>
>> What do you think ?
>
>
> Looks like a very practical approach.

One issue is that graphics routines will be pretty slow.
"Big pixels" use processor cycles and memory bandwidth.
Accelerating the processor helps that, but the peripheral
bus is still 1MB/sec max.

[sicklittlemonkey]

> "Big pixels" use processor cycles and memory bandwidth.

So do arcane pixel and raster mappings. ;-)

Stick with the simpler (but still better) scheme that lores uses. Two
pixels per byte, 16 colours. If linear mapping is used in main memory,
we get can 120x136 or 128x128 out of hires pages 1 and 2 with only 64
bytes wasted.

Alternatively the graphics memory for the extra mode could be placed on
the card only, and 'windowed' via I/O locations, with configurable
resolutions.

Realistically, the only ongoing development that might use such a mode
is going to be Contiki, so perhaps we should ask for Oliver's advice.

Cheers,
Nick.

[bie...@terra.es]

aiia...@gmail.com ha escrito:

> I added a link to your site on mine
> (http://rich12345.tripod.com)

Thanks, now I'm a "hardware hacker" .. :-)

> If you design the card using programmable
> logic, extra (non compatible) video modes
> could be added at any time.
>
> perhaps put a mechanical switch on the
> card that connects the PROGRAM pins
> of the logic device to the address/data
> bus. Re-Program the device (new program
> loaded off disk), flip the switch (no slot addresses
> taken by the card any longer), and you've
> got new logic on your card..

That's a good idea, only that it may be another whole project in
itself, it may mean much more development time and effort.
Don't you prefer to have this asap ?
Of course programmable logic is "the way to go".
So we better start learning some hdl...
The address scanner and the pixel generator can be made programable via
software up to a certain point, more or less like the 6545 in the videx
is: Bytes per scan line, lines per frame, graphics buffer start
address, etc. As long as the resulting frequencies fall within the
monitor specs and the memory map permits, all will be ok.

[bie...@terra.es]

>BTW there is no need for dual ported RAM: 500 nS out of every 1 mS 6502
>does not acess the memory. That's how the normal Apple video works.
>Using modern SRAM it is trivial to read 4 bytes in 500 nS (double scan
>rate AND double hi-res or 80 columns).

Yes you're right. But as you can't modify the Apple II timing this
complicates the access to the RAM from the side of the video generator.
If it were not because dual-ported RAM seems to be so much more
expensive. Still, it may fit in the fpga in the form of ip. I believe
it would ease the things a lot.

[bie...@terra.es]

>If you do plan on writing DHGR support.

DHGR has a problem: in order to mantain the aspect ratio, the pixel
image does need to have twice the height : the pixels in DHGR are not
square: a 560h*192v DHGR image must translate to a 560h*(192*2)v pixel
image if the aspect ratio has to be correct...

[bie...@terra.es]

>One issue is that graphics routines will be pretty slow.
>"Big pixels" use processor cycles and memory bandwidth.
>Accelerating the processor helps that, but the peripheral
>bus is still 1MB/sec max.

I don't get it. Why ? The a2 speed is not affected at all... ?

[bie...@terra.es]

>Alternatively the graphics memory for the extra mode could be placed on
>the card only, and 'windowed' via I/O locations, with configurable
>resolutions.

I have this question : what addresses should be chosen for this I/O
locations ?
If they fall in the i/o space of the slot, then the card won't be
"transparent" and you will not be able to "piggiback" another card on
it, and you'll loose a slot.
OTOH, are there any "unused" addresses in the (usual) $C000 range (i/o
space) ?

[bie...@terra.es]

> It can be forth try unless we have to find other way to add a new
>softswitch to support video mode for EGA and VGA. Apple II can't add new
>softswitches unless we should be able to modify softswitch logic on the
>motherboard.

You don't need to modify the motherboard.
The softswitches are in the vga card and only affect the video coming
out of the vga card.

>I have read if I understand, but I want to give you my thought. They
>claim to add incompatible video mode. Do you mean to add new softswitch for
>VGA? If it is the issue, I would suggest to have 256 colors at 320x200
>resolution. Total bytes are 64,000. You can divide it into 32,000. Main
>memory will have 32,000 bytes and aux memory will have 32,000 bytes. Both

>of them start at $2000 through $9D00...

Hmmm, we have to think carefully about this things.
Nowadays a common 17" LCD has 1280*1024 pixel, and this means 1.280
kilobytes @8bit screen depht... or 3 times as much for real color...
(did we mention color palletes yet ?)

Does an Apple II eat this ?

[bie...@terra.es]

Also, this sort of card is similar to a LCD driver card I'm interested
in. Instead of generating VGA, you take the existing video memory and
>use an LCD controller (I'm talking about raw LCD panels, not vga/ntsc
>input) and fill its memory directly. LCD controllers are memory mapped
>so they take care of displaying what's in there. The main problem is
>finding a surplus panel that's reasonably priced, is color, and also
>handles the resolution. You can find 320x240 and 640x480 panels that
>are cheap but the docs are almost nonexistent or you have to drive them
>directly without a premade controller (there appear to be a few popular
>ones so making a card for one of these would support a whole class on
>lcd panels). Once one of these works, an apple II laptop (a REAL one)
>would be much easier...

You can make a "laptop" with a VGA LCD + Apple IIc+.

ALL THE SIGNALS OF THIS DESIGN ARE AVAILABLE AT THE 6502 SOCKET
THIS MEANS :
THIS DESIGN WILL WORK ON THE Apple IIc/IIc+ TOO !!

All you need is a different form-factor for the vga card.

[Michael J. Mahon]

I wasn't talking about compatible modes, but about new modes
that require a larger frame buffer, and therefore more data
to be updated to produce a given effect.

[Michael J. Mahon]

Think about how long it will take an Apple to fill a 1.2MB (that's
*mega*bytes) frame buffer. There is a reason that higher resolutions
and color depths go with more powerful processors (and with more RAM).

[aiia...@gmail.com]

>The address scanner and the pixel generator can be made programable via
>software up to a certain point, more or less like the 6545 in the videx
>is: Bytes per scan line, lines per frame, graphics buffer start
>address, etc. As long as the resulting frequencies fall within the
>monitor specs and the memory map permits, all will be ok.

good idea!
some softswitch built into the card that controls these things.

>So we better start learning some hdl...

I'm learning VHDL. It's pretty easy to understand the examples
I've read and dissected. Applying what I've learned so far to
examples that *I* want to create is taking some time.

Rich

[aiia...@gmail.com]

>Think about how long it will take an Apple to fill a 1.2MB

Too long.

Even if the 6502 is running at 50mhz, imagine the nightmare
of bankswitching out 64k chunks, then moving data from the
active memory into the video buffer...

>There is a reason that higher resolutions
>and color depths go with more powerful
>processors (and with more RAM).

more powerful CPU = faster speed + more address lines. (and
more linear addressable RAM)

We can put 16 megabytes of RAM in an apple II using
AE bankswitch method (1 byte register selects which
64k block to present to the CPU. 256*64k= 16384k = 16megs)
but what a pain it is to deal with this!

Rich

[aiia...@gmail.com]

>Realistically, the only ongoing development that might use such a mode
>is going to be Contiki, so perhaps we should ask for Oliver's advice.

The problem with Contiki is that it FILLS 64k. No room for anything
else.

I was working a few years ago with a modified version of "split
personality"
that had hacked-prodos-compatibility.

I've come up with better ways to do it, but never got it to run (I
don't know
Prodos well enough)

If we can get it to work, up to 16megs (1 megabyte is common) will be
accessible to prodos. Contiki could be modified to load the AUX RAM
access program into main RAM (instead of an application, like the
web browser, etc)... Once the aux RAM access program is installed,
you could have as many apps running as your aux card allows.

bank1=web browser
bank2=mail
bank3=IRC
bank4=whatever

maybe figure out how to display HGR from a bank besides the
MAIN RAM, and then make contiki use Hi-Res graphics instead of
the text it uses now.

Some sort of AUX access program will have to be developed
before Contiki could use *any* video mode besides TEXT screen.

http://rich12345.tripod.com/split.html

http://rich12345.tripod.com/MTOS/MTOS.html

Rich

[Jorge Chamorro Bieling]

<aiia...@gmail.com> wrote:

It's not if you just want to have 132 colums and 128 rows of text.
Or you just want to be able to hplot 0,0 to 1150,980.
Then it's a BIG pain when you have to deal with this as a bitmap...

That's why we have to think carefully about this things...
--
Jorge Chamorro Bieling

[Mark McDougall]

Michael J. Mahon wrote:

> Think about how long it will take an Apple to fill a 1.2MB (that's
> *mega*bytes) frame buffer. There is a reason that higher resolutions
> and color depths go with more powerful processors (and with more RAM).

Yes, but what might be worth doing is adding tilemap/sprite support. That
relieves the CPU of doing a lot of data shuffling. Might even be able to
port some NES games across...

[Michael J. Mahon]

While the time to put a character in a buffer is constant regardless
of the frame buffer size, drawing a line is proportional to the size
of the frame buffer, so all line drawing will take longer.

> That's why we have to think carefully about this things...

That's my point. ;-)

Again, not an issue when simply "mirroring" the existing
modes, since all extra work is on the card.

[Michael J. Mahon]

Mark McDougall wrote:
> Michael J. Mahon wrote:
>
>> Think about how long it will take an Apple to fill a 1.2MB (that's
>> *mega*bytes) frame buffer. There is a reason that higher resolutions
>> and color depths go with more powerful processors (and with more RAM).
>
>
> Yes, but what might be worth doing is adding tilemap/sprite support.
> That relieves the CPU of doing a lot of data shuffling. Might even be
> able to port some NES games across...

Tiling is *exactly* the kind of approach that can reduce processor
overhead for a given pixel count--but, again, a large VGA display
mode will require either a *lot* of 8x8 tiles (better tile resolution,
but slower) or about 80x60 16x16 tiles (less tile resolution, but
faster).

[bie...@terra.es]

aiia...@gmail.com ha escrito:

> >The address scanner and the pixel generator can be made programable via
> >software up to a certain point, more or less like the 6545 in the videx
> >is: Bytes per scan line, lines per frame, graphics buffer start
> >address, etc. As long as the resulting frequencies fall within the
> >monitor specs and the memory map permits, all will be ok.
>
> good idea!
> some softswitch built into the card that controls these things.

some registers built into the card that control these things. :-)

>
> >So we better start learning some hdl...
>
> I'm learning VHDL. It's pretty easy to understand the examples
> I've read and dissected. Applying what I've learned so far to
> examples that *I* want to create is taking some time.

So, what block of the vga card diagram are you going to write in a hdl?

the dual ported ram ?
the softswitches state latch ?
the address scanner ?
the pixel & sync generator ?

choose one...

[Jorge Chamorro Bieling]

Michael J. Mahon <mjm...@aol.com> wrote:

>
> While the time to put a character in a buffer is constant regardless
> of the frame buffer size, drawing a line is proportional to the size
> of the frame buffer, so all line drawing will take longer.

I mean, I don't expect to see a nice full color photo of hawaii on the
a2 screen.
But I'd like to be able to draw a graph or some "complex" display of
let's say a wave with numbers and text and colors, for example, with a
decent resolution.
One is vectors/shapes/text the other is a bitmap.
You don't usually need to save this kind of drawings as a bitmap, rather
you redraw it from primitives.
In this sense, it makes sense.
As for the bitmaps, it doesn't.
--
Jorge Chamorro Bieling

[bie...@terra.es]

aiia...@gmail.com ha escrito:

> We can put 16 megabytes of RAM in an apple II using
> AE bankswitch method (1 byte register selects which
> 64k block to present to the CPU. 256*64k= 16384k = 16megs)
> but what a pain it is to deal with this!

Hmm, yes, if the card replaced the ramworks... ?
Great idea. Why just hold a copy of the aux ram when it can *be* the
aux ram ?
The memory was going to be there anyway.
And it does not complicate it, as it's only a matter of interfacing the
memory's OE or leaving it grounded, and the softswitches were being
monitored anyway.
What you do and how you do it with respect to the banks' contents is
another story.
Be it frame buffers or a ram disk...
Dealing with it is a pain, as it has always been.
The VGA card does not help in this respect, it's an Apple II after all.
Thanks for the idea, rich.

[Jorge Chamorro Bieling]

<aiia...@gmail.com> wrote:

> oops
>
> BIT=1
> for v=0 to 191
> Get V address
> for H=0 to 279
>
> for bitcount = 1 to 7
>
> get data at Vaddress,H
> AND with BIT
> display on screen (change timing to stretch pixels)
> ROL BIT
> next bitcount
> BIT=1
> next h
> next v

for V=0 to 191
Get V address
for H=0 to *39*
get data at Vaddress,H
BIT=1
for bitcount = 1 to 7
AND with BIT
display on screen (change timing to stretch pixels)
ROL BIT
next bitcount
next H
next V

:-)
--
Jorge Chamorro Bieling

[Jorge Chamorro Bieling]

Michael J. Mahon <mjm...@aol.com> wrote:

>
> While the time to put a character in a buffer is constant regardless
> of the frame buffer size, drawing a line is proportional to the size
> of the frame buffer, so all line drawing will take longer.

You mean
1. drawing a longer line takes longer
or
2. drawing the same lenght line takes longer

??
--
Jorge Chamorro Bieling

[Lyrical Nanoha]

Didn't one of the Lasers have a 560x384 mode and support for up to 80x48
text by sticking page 1 above page 2?

-uso.

[Jorge Chamorro Bieling]

Lyrical Nanoha <Lyrica...@dosius.ath.cx> wrote:

>
> Didn't one of the Lasers have a 560x384 mode and support for up to 80x48
> text by sticking page 1 above page 2?

I don't know. But if you show HGR1 and HGR2 side by side, and then you
put below HGR1(AUXMEM) and HGR2(AUXMEM) side by side, then you've got a
mosaic of 560*384 pixels where you can even plot quite easily from
basic. Showing this mosaic is going to be a feature of this card because
it's so easy to do just by scanning the addresses in the right
sequence...

This image will cost you 32Kb of RAM, though.
--
Jorge Chamorro Bieling

[Jorge Chamorro Bieling]

Michael J. Mahon <mjm...@aol.com> wrote:

>
> I wasn't talking about compatible modes, but about new modes
> that require a larger frame buffer, and therefore more data
> to be updated to produce a given effect.

I see. Of course. Then we throw in an accelerator too ?

[Alex Freed]

bie...@terra.es wrote:
>
> Yes you're right. But as you can't modify the Apple II timing this
> complicates the access to the RAM from the side of the video generator.
> If it were not because dual-ported RAM seems to be so much more
> expensive. Still, it may fit in the fpga in the form of ip. I believe
> it would ease the things a lot.
>

If an FPGA is used, the internal BRAM (block RAM) is organized as dual
port memory anyway, so it's a no-brainer.
If the card is built with regular RAM (say the surplus cache chip from
an old 486 motherboard) and discrete logic and/or CPLDs then transparent
video RAM access is still quite simple. Run the board clock at say 8
times the Apple clock and read the video RAM 4 times during the 500 nS
of the Apple 2 video cycle. As you said the dual-ported RAM is quite
expensive. Old cache RAM is virtually free.

[Jorge Chamorro Bieling]

Alex Freed <al...@mirrow.com> wrote:

>
> If an FPGA is used, the internal BRAM (block RAM) is organized as dual
> port memory anyway, so it's a no-brainer.

What's the size of these memories ?

> If the card is built with regular RAM (say the surplus cache chip from
> an old 486 motherboard) and discrete logic and/or CPLDs then transparent
> video RAM access is still quite simple. Run the board clock at say 8
> times the Apple clock and read the video RAM 4 times during the 500 nS
> of the Apple 2 video cycle. As you said the dual-ported RAM is quite
> expensive. Old cache RAM is virtually free.

Yes. In fact the memory is also yours during every 6502 read cycle. And
most of the time during write cycles too, let's say 400nS, because 100
nS (the last 100nS of the 6502 write cycle) is plenty of time for a
write at today's memories' speeds (5-15nS).

But, what makes me feel uncomfortable is:

1.- Shared RAM access is constrained to certain time solts, and
therefore, both parts of the system must run synchronously which means
more design effort and multiplexing circuitry.

You see it as: "Standard memory is cheaper, and there's a way to go with
it". And then you're right. still... hmmm I see the dual-ported ram
design as bright and clean, and the other as a pain to suffer because
the dual port ram happens to be so expensive.

2.- The standard memory approach makes the design phase0-dependant, and
this means it won't neccesarily work in the Apple IIc+. At least without
additional care == design effort. And then only if it's worth it. And
what would happen if the Apple IIc+ was overclocked ?

Regards,
--
Jorge Chamorro Bieling

[sicklittlemonkey]

> I see. Of course. Then we throw in an accelerator too ?

And make it a RAM card too.
That would negate your worries about losing a slot.

Basically a replacement motherboard on a card. ;-)

Cheers,
Nick.

[sicklittlemonkey]

There are 5 locations listed as reserved here:
http://www.sheppyware.net/tech/hardware/softswitches.html

I haven't double-checked them all, but $C020 is the cassette port, so
you don't want to use that. The $C040/2/3 ones look good.

Cheers,
Nick.

[sicklittlemonkey]

That won't help you draw lines any faster though. ;-)
(Ok, special cased ones: 0, 45, 90 degrees etc.)

Good for a window manager though, and some games.
Text page 1 could be bank switched to access the grid.

Cheers,
Nick.

[Mark McDougall]

Jorge Chamorro Bieling wrote:

> You see it as: "Standard memory is cheaper, and there's a way to go
> with it". And then you're right. still... hmmm I see the dual-ported
> ram design as bright and clean, and the other as a pain to suffer
> because the dual port ram happens to be so expensive.

I agree, the dual-port idea is much less painful. But that means large
(== expensive) FPGA or some external DPRAM which also increases the
minimum I/O count of your chosen device.

I don't know much about A2 hardware, but a colleague mentioned some
vague recollection he had about doing 'tricky' things with A2 graphics
timings to get 'special effects' (he couldn't give me anything more
concrete than that). I'm assuming he's talking about updating A2 video
RAM at strategic points in time to get undocumented behaviour...

If this is indeed the case, you're going to lose that capability if
you're 'screen-scraping' the A2 video RAM completely asynchronously. IIR
I do notice that Slot 7 has the VBLANK/VSYNC signal on it. But that my
not be enough...

FWIW, if you're going to stick a *large* FPGA on it, you may as well
include a cheap USB host chip, some (more) RAM and CF adapter. That way
you can make a multi-function card which does VGA, takes USB
keyboard/mouse, has extra RAM, and Compact Flash.

For all the talk about how difficult it would be to create an 8-bit
micro 'USB card', if you only want keyboard/mouse, it would be trivial
to get, say a Cypress USB host chip, and write firmware on the chip to
talk to a HID USB keyboard, emulate the A2 keyboard chip in the FPGA -
no A2 driver software necessary.

Regards,
Mark

[sicklittlemonkey]

> But if you show HGR1 and HGR2 side by side ...

I have thought about this before, and other variations, but you still
have the colour limitations of hires. Still, if you're going to throw
it in, why not bank switch the different screens into HGR1. That way
all code can just deal with that page, and forget about the hassles
with aux memory.

In fact, you could do the same thing with LGR1. Bank switch 16 pages
there and you could do a 160x192 version of double hires with nicer
pixel addressing.

Crufty, I know. Maybe the tile map idea is better.

Cheers,
Nick.

[PZ]

Then all we'd need is the source to Mouse Desk and PublishIt 4 and we
could go crazy.

- Paul

[Alex Freed]

Jorge Chamorro Bieling wrote:
> What's the size of these memories ?

The smallest Spartan 3 FPGA that costs about $10 has 8K of BRAM.
Should be only enough for a single HGR screen. The bigger XC3S200 (about
$15) has 24K of BRAM and enough gates to contain ALL of Apple 2
including the 6502. That's the one I've used in the FPGApple.

XC3S200 plus an old cache chip is probably the cheapest solution.

> 1.- Shared RAM access is constrained to certain time solts, and
> therefore, both parts of the system must run synchronously which means
> more design effort and multiplexing circuitry.

True, but very easy to do. Using the programmable logic all the
complexity boils down to a few lines of Verilog/VHDL.

>
> You see it as: "Standard memory is cheaper, and there's a way to go with
> it". And then you're right. still... hmmm I see the dual-ported ram
> design as bright and clean, and the other as a pain to suffer because
> the dual port ram happens to be so expensive.

If your goal is the "cleanest" design possible, I rest my case.
However I do design hardware for a living. For decades... And my goal is
always to get the right functionality out of minimum hardware both in
terms of cost and number of chips.

>
> 2.- The standard memory approach makes the design phase0-dependant, and
> this means it won't neccesarily work in the Apple IIc+. At least without
> additional care == design effort. And then only if it's worth it. And
> what would happen if the Apple IIc+ was overclocked ?

Last time I looked at a IIc it didn't have any slots, so a "card" for a
IIc would have to be a separate design one way or the other.

Also it doesn't have to be phase0-dependant. Consider this design:

1. Regular memory is used with 20 nS access cycle - a dime a dosen.
2. We run a 28 MHz clock that doesn't have to be syncronized to phase0.
3. VGA uses 14 MHz shift clock in 40 char mode (and normal graphics
modes) and 28 MHz for 80 col/double HGR modes. Then it needs to read a
byte every 7 clocks. So we designate the first cycle out of every 7 for
video access. If the CPU wants to read/write memory at the same time, it
will have to "wait" at most 35 nS. Which means no wait at all - all done
in the same phase0 cycle. We want to latch the data read from RAM so
that it is stable when the CPU actually reads it.

This is very easy to implement even with standard 74xx parts.

-Alex.

[Michael J. Mahon]

Mark McDougall wrote:
> Jorge Chamorro Bieling wrote:
>
>> You see it as: "Standard memory is cheaper, and there's a way to go
>> with it". And then you're right. still... hmmm I see the dual-ported
>> ram design as bright and clean, and the other as a pain to suffer
>> because the dual port ram happens to be so expensive.
>
>
> I agree, the dual-port idea is much less painful. But that means large
> (== expensive) FPGA or some external DPRAM which also increases the
> minimum I/O count of your chosen device.
>
> I don't know much about A2 hardware, but a colleague mentioned some
> vague recollection he had about doing 'tricky' things with A2 graphics
> timings to get 'special effects' (he couldn't give me anything more
> concrete than that). I'm assuming he's talking about updating A2 video
> RAM at strategic points in time to get undocumented behaviour...

He was talking about switching video display modes at precisely
timed points in the raster to allow arbitrary "mixing" of video
display modes on the screen.

> If this is indeed the case, you're going to lose that capability if
> you're 'screen-scraping' the A2 video RAM completely asynchronously. IIR
> I do notice that Slot 7 has the VBLANK/VSYNC signal on it. But that my
> not be enough...

All the video softswitch references can also be snooped on the
bus, so the issue is not knowing that they are occurring, but
synchronizing their effects to produce corresponding effects
on the VGA display. I agree that this will be difficult unless
the VGA raster is kept in sync with the Apple II raster, meaning
that the horizontal scan frequency is exactly twice the Apple
scan frequency, the vertical scan frequency is exactly the Apple
vertical frequency, and they are phase locked. Further, the
exact point of the softswitch changes will have to be marked
and used on two successive "replays" of each line.

This is an example of "painful compatibility" since is severely
restricts design choices to obtain the last .01% compatibility.

A synchronous scan doubler handles all these cases transparently.

> FWIW, if you're going to stick a *large* FPGA on it, you may as well
> include a cheap USB host chip, some (more) RAM and CF adapter. That way
> you can make a multi-function card which does VGA, takes USB
> keyboard/mouse, has extra RAM, and Compact Flash.
>
> For all the talk about how difficult it would be to create an 8-bit
> micro 'USB card', if you only want keyboard/mouse, it would be trivial
> to get, say a Cypress USB host chip, and write firmware on the chip to
> talk to a HID USB keyboard, emulate the A2 keyboard chip in the FPGA -
> no A2 driver software necessary.

But that will require a "flying cable" from the card to the keyboard
connector, and a switch matrix emulation for machines prior to the
IIgs and an ADB emulation for the IIgs.

[Michael J. Mahon]

Here is the moment of truth...

Is it a VGA adapter for an Apple II or is it a *replacement*
for an Apple II?

And all this seems easier and cleaner to you than just keeping
some 15kHz monitors running?

[Michael J. Mahon]

Trust me, when people are talking VGA, they are talking about
*picture*, not just *diagrams*.

And, as I mentioned, even the diagrams you describe will take
several times as long to draw as it takes to draw them (in
lower resolution and limited colors) on the Apple II screen.

TANSTAAFL

[Michael J. Mahon]

I mean that a line that is half the width of the screen takes
longer, because it has 1) more pixels, and 2) each pixel has
more bits.

If we are looking at vectors, then the time for a constant speed
processor to draw them goes up as the square root of the frame
buffer size. (Of course, the time to fill an area goes up
directly with frame buffer size.)

[Alex Freed]

Michael J. Mahon wrote:
>
> But that will require a "flying cable" from the card to the keyboard
> connector, and a switch matrix emulation for machines prior to the
> IIgs and an ADB emulation for the IIgs.

I don't agree. Apple 2 uses an ascii code from a keyboard. A 7 bit code
with the MSB indicating that a byte is ready. No switch matrix to
emulate. That is a pain in the butt as I know from a ZX Spectrum in an
FPGA project.

However I don't think USB interface for a keyboard is called for. Most
keyboards in non-Mac world use a PS/2 interface that is infinitely
easier to support.

[sicklittlemonkey]

Heh.

By *pictures* do you mean *etchings*? ;-)
Also *diagrams* is a good codeword for that.

Let's not forget what historically drove video upgrades!

Cheers,
Nick.

[bie...@terra.es]

Michael J. Mahon ha escrito:

> Jorge Chamorro Bieling wrote:
> > Michael J. Mahon <mjm...@aol.com> wrote:
> >
> >
> >>While the time to put a character in a buffer is constant regardless
> >>of the frame buffer size, drawing a line is proportional to the size
> >>of the frame buffer, so all line drawing will take longer.
> >
> >
> > You mean
> > 1. drawing a longer line takes longer
> > or
> > 2. drawing the same lenght line takes longer
>
> I mean that a line that is half the width of the screen takes
> longer, because it has 1) more pixels, and 2) each pixel has
> more bits.
>
> If we are looking at vectors, then the time for a constant speed
> processor to draw them goes up as the square root of the frame
> buffer size. (Of course, the time to fill an area goes up
> directly with frame buffer size.)

Yes, at "constant speed" for any given depth

1.- It takes n times longer to draw n*x pixels as it takes to draw x
pixels. (lines)
2.- It takes n*n times longer to draw of n*x*n*x pixels as it takes to
draw x*x pixels. (areas)

But "takes longer" is not a measure of drawing speed.
The space, measured in pixels, is missing in this equation :
(drawing speed) = (pixels drawn) / (time to draw them).

And the frame buffer size is not, nor direct nor indirectly, in this
equation.

So a drawing only "takes longer"

1.- When you are drawing more pixels (so obvious!).
2.- For frame buffers whose *depth* is bigger not whose *size* is
bigger.

The VGA card DOES NOT slow drawing speed at all... :-)

[Jorge Chamorro Bieling]

sicklittlemonkey <Nick.W...@gmail.com> wrote:

>
> By *pictures* do you mean *etchings*? ;-)
> Also *diagrams* is a good codeword for that.

yes, pcbs... :-)
--
Jorge Chamorro Bieling

[Mark McDougall]

Alex Freed wrote:

>> But that will require a "flying cable" from the card to the keyboard
>> connector, and a switch matrix emulation for machines prior to the
>> IIgs and an ADB emulation for the IIgs.
>
> I don't agree. Apple 2 uses an ascii code from a keyboard. A 7 bit code
> with the MSB indicating that a byte is ready. No switch matrix to
> emulate. That is a pain in the butt as I know from a ZX Spectrum in an
> FPGA project.

Exactly. And even if that wasn't the case, it would be simple to create FPGA
images for each 'flavour' and then program the device with whichever the
user requires.

As for the 'flying lead' - not needed - I'd suggest disabling/removing the
AY3600 entirely and have the card respond to accesses at the appropriate
memory locations.

> However I don't think USB interface for a keyboard is called for. Most
> keyboards in non-Mac world use a PS/2 interface that is infinitely
> easier to support.

People have asked for it. Yes, PS2 is easier, but you'll find PS2 keyboards
are starting to slowly disappear.... bought a Dell lately?

Regards,

--
| Mark McDougall | "Electrical Engineers do it
| <http://members.iinet.net.au/~msmcdoug> | with less resistance!"

[Mark McDougall]

Michael J. Mahon wrote:

> Here is the moment of truth...
> Is it a VGA adapter for an Apple II or is it a *replacement*
> for an Apple II?

To be honest, if you stuck a mid-range FPGA on a card with video, RAM and
compact flash, you'd probably have enough capacity left over to implement
the entire Apple II in the FPGA. I mean, look at the A2 - a board full of
TTL and a 6502 - it's not that much logic for today's programmable logic
devices.

Of course, it's a matter of personal preference...

Some insist on using all original apple hardware, down to floppy drives and
monitor, and nothing short will suffice.

Some want to use the apple machine hardware, but due to lack of space or
resources, would like to be able to use a VGA monitor. Some would also use a
PC keyboard so they can use a KVM switch.

Some would be happy with a 'C-One' type setup, happy to use an apple
emulated in hardware with modern peripherals such as keyboard and compact flash.

Others again are happy to use software emulators running on the PC.

Personally, I want *all* of the above! ;)

[Mark McDougall]

sicklittlemonkey wrote:

> Let's not forget what historically drove video upgrades!

You mean games!?!

[Mark McDougall]

bie...@terra.es wrote:

> But "takes longer" is not a measure of drawing speed. The space, measured
> in pixels, is missing in this equation : (drawing speed) = (pixels drawn)
> / (time to draw them).

There is another factor to the equation - the memory architecture of the
frame buffer. The A2 video memory map is, from a software point of view,
quite simply ghastly! The calculations to find a video pixel memory address
are orders of magnitude greater than simply shifting an address or even
being able to simply increment an address when crossing a byte boundary.

Any 'enhanced' video mode would most likely have a much, much nicer
addressing scheme for the frame buffer.

And that will make a difference - particularly in BASIC.

[aiia...@gmail.com]

would be very nice to have Hires pg1, pg2, and a text screen
showing on the monitor all at once. I've asked the programmers
of AppleWin to add this before.

Rich

[Michael J. Mahon]

Yes, but the //e uses a switch matrix interface--the encoder is on the
main board. (Sorry for saying "prior to the IIgs" when I meant only
the //e--it's just that there are so many more //e's than ][ and ][+
machines.)

[Michael J. Mahon]

Mark McDougall wrote:
> Alex Freed wrote:
>
>>> But that will require a "flying cable" from the card to the keyboard
>>> connector, and a switch matrix emulation for machines prior to the
>>> IIgs and an ADB emulation for the IIgs.
>>
>>
>> I don't agree. Apple 2 uses an ascii code from a keyboard. A 7 bit
>> code with the MSB indicating that a byte is ready. No switch matrix to
>> emulate. That is a pain in the butt as I know from a ZX Spectrum in an
>> FPGA project.
>
>
> Exactly. And even if that wasn't the case, it would be simple to create
> FPGA images for each 'flavour' and then program the device with
> whichever the user requires.
>
> As for the 'flying lead' - not needed - I'd suggest disabling/removing
> the AY3600 entirely and have the card respond to accesses at the
> appropriate memory locations.

It's a little harder than that. The encoder is multiplexed with
other main board inputs before getting to the data bus.

Either you have flying leads or you put most of the Apple II on
the card, including pushbutton inputs, etc. (BTW, you have to
supply the pushbutton inputs anyway to get Open-Apple, Closed-
Apple, and the Shift key mod.)

>> However I don't think USB interface for a keyboard is called for. Most
>> keyboards in non-Mac world use a PS/2 interface that is infinitely
>> easier to support.
>
>
> People have asked for it. Yes, PS2 is easier, but you'll find PS2
> keyboards are starting to slowly disappear.... bought a Dell lately?

Everything is slowly disappearing...including us. ;-)

-michael

Parallel computing for 8-bit Apple II's!

[Michael J. Mahon]

Mark McDougall wrote:
> Michael J. Mahon wrote:
>
>> Here is the moment of truth...
>> Is it a VGA adapter for an Apple II or is it a *replacement*
>> for an Apple II?
>
>
> To be honest, if you stuck a mid-range FPGA on a card with video, RAM
> and compact flash, you'd probably have enough capacity left over to
> implement the entire Apple II in the FPGA. I mean, look at the A2 - a
> board full of TTL and a 6502 - it's not that much logic for today's
> programmable logic devices.
>
> Of course, it's a matter of personal preference...
>
> Some insist on using all original apple hardware, down to floppy drives
> and monitor, and nothing short will suffice.
>
> Some want to use the apple machine hardware, but due to lack of space or
> resources, would like to be able to use a VGA monitor. Some would also
> use a PC keyboard so they can use a KVM switch.
>
> Some would be happy with a 'C-One' type setup, happy to use an apple
> emulated in hardware with modern peripherals such as keyboard and
> compact flash.
>
> Others again are happy to use software emulators running on the PC.
>
> Personally, I want *all* of the above! ;)

I hear you.

But with all those different "wants", doesn't it seem likely that the
number of people who would acquire any specific thing is a little thin?

This sounds like a very fragmented "market". And, starting from a "user
base" many times larger, how many C-One's have been sold?

Hey, I'm not a cynic--just a realist. ;-)

Of course, if someone wants to invest their time, effort, and money to
build something interesting *just because they want to*, I love it!

Returning to the VGA topic, it's more than a little ironic that all the
VGA monitors out there could handle NTSC scan standards trivially for
an incremental cost of a dollar or so, if it were a design objective.

[Sean Fahey]

Porn?

[Michael J. Mahon]

LOL! I'd forgotten that important point. Without
porn, VCRs might never have made it from the early
adopters to the rest of us!

-michael

Parallel computing for Apple II's!

[Mark Frischknecht]

While we are dreaming about this. I want a Dual-Head option!

[Michael J. Mahon]

The size of the frame buffer is a full screen of pixels.

The size of an Apple II HGR frame buffer is 8KB, for example.

If you provide an enhanced resolution mode that has, say,
one byte per pixel, and 480,000 pixels (800x600), then
the frame buffer is 480KB, or sixty times larger than the
HGR frame buffer, and one should expect that lines of the
same length (on the screen) will take about SQRT(60) times
longer to draw, since that many more pixels are drawn.

> So a drawing only "takes longer"
>
> 1.- When you are drawing more pixels (so obvious!).
> 2.- For frame buffers whose *depth* is bigger not whose *size* is
> bigger.
>
> The VGA card DOES NOT slow drawing speed at all... :-)

Remember, I was talking about *enhanced* (not compatible) modes
that provide either more resolution or more color depth or both.
You apparently think I was talking about using a VGA monitor to
display the normal Apple II video modes.

I am merely stating the obvious a bit more precisely, and pointing
out that you will not be happy with a 1MHz processor drawing at
typical VGA resolutions.

There is a reason that the Apple II has relatively low resolution
graphics, and that the 2.8MHz IIgs made only modest improvements
with SHR.

People need to understand that adding a high resolution VGA mode
to an Apple II does not make it a modern processor.

It would be nice, I concede, to be able to attach an Apple II to
a VGA monitor, with a stable but blocky display. It would be much
less useful to try to do something interesting with that monitor
in a high resolution mode.

[Michael J. Mahon]

Mark McDougall wrote:
> bie...@terra.es wrote:
>
>> But "takes longer" is not a measure of drawing speed. The space, measured
>> in pixels, is missing in this equation : (drawing speed) = (pixels drawn)
>> / (time to draw them).
>
>
> There is another factor to the equation - the memory architecture of the
> frame buffer. The A2 video memory map is, from a software point of view,
> quite simply ghastly! The calculations to find a video pixel memory
> address are orders of magnitude greater than simply shifting an address
> or even being able to simply increment an address when crossing a byte
> boundary.
>
> Any 'enhanced' video mode would most likely have a much, much nicer
> addressing scheme for the frame buffer.

Not really, since the BASIC interface to graphics is all in machine
language. The built-in routines do not use the obvious, but space-
consuming, acceleration of table lookup for the starting address of
each horizontal line, but most games do. And horizontal pixel
addressing, though it still requires bit manipulation, can be sped
up significantly by using tables, too.

Further, anything besides 8-bits per pixel is going to require some
bit stuffing, regardless of frame buffer organization.

In most games/animations, most of the drawing time is in 'bitblt',
and speeds are quite directly proportional to the number of bytes
touched.

[sicklittlemonkey]

> You mean games!?!

Oh, is that what inspired the IIGS 3200 mode? ;-)

Cheers,
Nick.

[sicklittlemonkey]

And kingmakers they are still.

Apart from driving trends online and also in cell phone technology,
they might choose the next HD DVD format for us. What an unlikely
source of authority! Evolution in action ...

Anyway, back on topic. It seems a shame for the Apple II to be left out
at this stage, so we better soup this card up some more.

I propose we skip DVD playback, and aim for Blu-ray!

Cheers,
Nick.

[Mark McDougall]

Mark Frischknecht wrote:

> While we are dreaming about this. I want a Dual-Head option!

Why stop there? I want PIP so I can watch the cricket in the corner of
my A2 screen whilst playing Lode Runner. ;)

Regards,
Mark

[Mark McDougall]

Michael J. Mahon wrote:

> Not really, since the BASIC interface to graphics is all in machine
> language.

Obviously...

The built-in routines do not use the obvious, but space-
> consuming, acceleration of table lookup for the starting address of
> each horizontal line, but most games do. And horizontal pixel
> addressing, though it still requires bit manipulation, can be sped up
> significantly by using tables, too.

What, you don't think a few instruction decodes, plus a memory access or
two, with a few additions isn't orders of magnitude slower than a single
register shift?

Anyway, the point I was making is that the A2 graphics memory mapping,
even in ML, is going to make an impact on the speed of any graphics
routines on a 2MHz A2 - particular a brain-dead pixel-by-pixel
line-drawing algorithm.

Regards,
Mark

[Mark McDougall]

Michael J. Mahon wrote:

> I am merely stating the obvious a bit more precisely, and pointing
> out that you will not be happy with a 1MHz processor drawing at
> typical VGA resolutions.

Yes. It's probably worth pointing out that modern (PC) graphics cards
have processors that rival (and indeed even exceed) the processing power
of your motherboard CPU - not to mention up to 2.1GB/s bus bandwidth
(AGP 8x).

I'll leave it as an exercise for the reader to work out how long it
would take to push 2.1GB across the A2 bus! ;)

Regards,
Mark

[sicklittlemonkey]

> I want a Dual-Head option!

If Mr Frischknecht was staying on (off) topic, I think he was making a
rather different request! Why he would want two is beyond me. ;-)

My request would be for a Head-Up-Display!

Cheers,
Nick.

[Mark McDougall]

Michael J. Mahon wrote:

> But with all those different "wants", doesn't it seem likely that the
> number of people who would acquire any specific thing is a little thin?

Yes, but I'm always surprised at how many people seem to be making a
business out of selling hardware for retro systems - though perhaps they're
not actually making any money out of it?!?

> This sounds like a very fragmented "market". And, starting from a "user
> base" many times larger, how many C-One's have been sold?

Sadly, I fear it is far less than what was originally projected. I've heard
that one distributor has been stuck with a lot of stock and has been trying
to sell it at a loss - still with no takers. Also, it does still appear to
have teething problems with the firmware, and support is rather 'informal'
at best.

Pity, because it's a great idea, and I've almost been tempted to get one
myself. Trouble is, there are only a couple of (unfinished) cores available
for it, including VIC-20, C-64 and Amstrad CPC (not exactly setting the
world on fire). Also personally, I think the FPGA is a little small, and
there's a 2nd closed-source FPGA on there to interface with Compact Flash,
video and I/O which I think detracts from the appeal to home-brew developers
somewhat.

> Of course, if someone wants to invest their time, effort, and money to
> build something interesting *just because they want to*, I love it!

I'd be happy to develop a product if only I could be sure that I'd get my
money back - or perhaps enough profit for a few beers! I don't mind doing
this stuff just for the love of it!

[Mark McDougall]

sicklittlemonkey wrote:

> If Mr Frischknecht was staying on (off) topic, I think he was making a
> rather different request! Why he would want two is beyond me. ;-)

One for each hand, perhaps? ;)

[Vince Briel]

> Yes, but I'm always surprised at how many people seem to be making a
> business out of selling hardware for retro systems - though perhaps
> they're not actually making any money out of it?!?

Yeah, there isn't much market, just enough to sell a few items.

>> Of course, if someone wants to invest their time, effort, and money to
>> build something interesting *just because they want to*, I love it!

That is where most of the vintage products are coming from. Somebody wanted
something, so they built it and then find out more people want one too.

>
> I'd be happy to develop a product if only I could be sure that I'd get my
> money back - or perhaps enough profit for a few beers! I don't mind doing
> this stuff just for the love of it!

Ah hah, the true reason for developing, the beer factor! You can't ever
expect the vintage market to bring a profit, the best you can hope for is a
return on investment. Anything else is a bonus.

Vince

Replica 1 the Apple 1 clone
http://www.brielcomputers.com

[aiia...@gmail.com]

>I could make either a video for VGA or a whole FPGApple available
>commercially if I new there was a market.

I'm making and Apple peripheral slot connector to Spartan3 adaptor.

I cut a super serial card apart, do you have suggestions for which
pins on the Spartan to route to the pins on the Apple bus?

Rich

[Michael J. Mahon]

Mark McDougall wrote:
> Michael J. Mahon wrote:
>
>> But with all those different "wants", doesn't it seem likely that the
>> number of people who would acquire any specific thing is a little thin?
>
>
> Yes, but I'm always surprised at how many people seem to be making a
> business out of selling hardware for retro systems - though perhaps
> they're not actually making any money out of it?!?

I have the same feeling, but hope springs eternal...

>> This sounds like a very fragmented "market". And, starting from a
>> "user base" many times larger, how many C-One's have been sold?
>
>
> Sadly, I fear it is far less than what was originally projected. I've
> heard that one distributor has been stuck with a lot of stock and has
> been trying to sell it at a loss - still with no takers. Also, it does
> still appear to have teething problems with the firmware, and support is
> rather 'informal' at best.

This is not an unusual situation.

The folk(s) who did the initial creation were driven by the desire
to show that it could be done. After that's accomplished, they seldom
have the patience for the slow and tiresome business of making it "just
right".

With the initial enthusiasm spent, and the slogging work ahead, a
project often loses focus and grinds to a virtual halt.

> Pity, because it's a great idea, and I've almost been tempted to get one
> myself. Trouble is, there are only a couple of (unfinished) cores
> available for it, including VIC-20, C-64 and Amstrad CPC (not exactly
> setting the world on fire). Also personally, I think the FPGA is a
> little small, and there's a 2nd closed-source FPGA on there to interface
> with Compact Flash, video and I/O which I think detracts from the appeal
> to home-brew developers somewhat.

Yep--feasibility demonstrated, focus lost.

>> Of course, if someone wants to invest their time, effort, and money to
>> build something interesting *just because they want to*, I love it!
>
>
> I'd be happy to develop a product if only I could be sure that I'd get
> my money back - or perhaps enough profit for a few beers! I don't mind
> doing this stuff just for the love of it!

Just out of curiosity, how much would it cost to "get your money back"?
(I'm glad to hear it's OK not to get your time back.)

[Michael J. Mahon]

sicklittlemonkey wrote:
> And kingmakers they are still.
>
> Apart from driving trends online and also in cell phone technology,
> they might choose the next HD DVD format for us. What an unlikely
> source of authority! Evolution in action ...

I certainly hope *someone* has the nerve to choose one--the
CE market is clueless. ;-(

"Insanity is doing the same thing over and over, each time
expecting a different result."

> Anyway, back on topic. It seems a shame for the Apple II to be left out
> at this stage, so we better soup this card up some more.
>
> I propose we skip DVD playback, and aim for Blu-ray!

Now you're talking! ;-)

-michael

Music synthesis for 8-bit Apple II's!

[aiia...@gmail.com]

>So, what block of the vga card diagram are you going to write in a hdl?
>
>the dual ported ram ?

8k RAM with two data/address busses, a select
line chooses which of these two to actually control
the RAM

>the softswitches state latch ?

watch for accesses to $C000, and keep a copy
of what state the Apple II video circuits are currently
in.

>the address scanner ?

scan through the dual port RAM in the display
order, and send to the p&s generator

>the pixel & sync generator ?

generate VGA signal, proper pixel color,
placement on screen, stretch pixel to screen,

My attempted definitions are above...

Define each in greater detail, and I'll pick one or more.

We also have to take into account Text mode, and have
the character ROM (custom?) in the circuit. we can either
use the APple character ROM, or design our own bitmap
that displays nice on the increased resolution screen.

Rich

[Michael J. Mahon]

Mark McDougall wrote:

> Anyway, the point I was making is that the A2 graphics memory mapping,
> even in ML, is going to make an impact on the speed of any graphics
> routines on a 2MHz A2 - particular a brain-dead pixel-by-pixel
> line-drawing algorithm.

I agree that linear addressing will make a positive difference,
and in the case of the slower BASIC routines, they may be rewritten
to get a significant speedup. But in more general cases, like
animation, I doubt that it will make enough of a difference to
compensate for any sizeable increase in the number of pixels affected
in a graphics operation. People have found many ways to mitigate the
apparent performance issues of non-linear addressing and bit-stuffing.

Before building anything, I recommend actually coding such routines
and assessing their performance for "enhanced" graphics modes to
determine the actual speed with which an unaccelerated Apple can
use such a mode.

They'll have to be coded anyway to make the mode(s) useful, so why not
code them and evaluate designs beforehand to guide design tradeoffs
and set realistic expectations for graphics performance?

[aiia...@gmail.com]

>>the dual ported ram ?

>8k RAM with two data/address busses, a select
>line chooses which of these two to actually control
>the RAM

$400 to $800 = text OR lo-res screen 1kilobyte
$800 to $1600 = text OR lo-res screen 2 1 kilobyte

$2000 - $3FFF = hires screen 1 8 kilobytes
$4000 - $4FFF = hires screen 2 8kilobytes

18k dual port RAM? It only has to be READ
by the card, not written to (unless we make
some hardware based sprite generator that
stores into RAM as well as being displayed)

Alex Freed wrote:

>BTW there is no need for dual ported RAM: 500 nS out of every 1 mS 6502
>does not acess the memory. That's how the normal Apple video works.
>Using modern SRAM it is trivial to read 4 bytes in 500 nS (double scan
>rate AND double hi-res or 80 columns).

I understand the scheme, but will it work?

Grabbing the video data off the bus (according to which address
is being accessed by the CPU), and directly sending it to the
VGA screen...

The apple II screen is refreshed at 60hz. What does a VGA
refresh at?

loop
wait for video address on address bus
get byte from databus
send to VGA
goto loop

Won't the VGA screen refresh several times while the
video generator in the apple II is accessing 1 frame?

[aiia...@gmail.com]

>So, what block of the vga card diagram are you going to write in a hdl?
>

>the dual ported ram ?

8k RAM with two data/address busses, a select
line chooses which of these two to actually control
the RAM

>the softswitches state latch ?

[aiia...@gmail.com]

>Hmm, yes, if the card replaced the ramworks... ?
>Great idea. Why just hold a copy of the aux ram when it can *be* the
>aux ram ?

6502 + RAM + ROM + video generator + keyboard decoder + disk drive
(flash memory card), all on a card... Alex Freed, Gary Becker, Mark
McDougall
already have these things working.

These FPGA's have TONS of I/O.

add (within the HDL) references to the i/o pins, and change the state
of those pins depending on what is going on within the FPGA apple II.
put the data, address bus on the I/O pins, create an adaptor that you
can plug into the apple II slot, then plug the FPGA card into. A
docking
station in an apple II slot.

Add a "slave" mode to the FPGA apple. Instead of getting keyboard
data from the PS2 connector on the FPGA board, grab it off the
apple II bus. Select which slots will be "emulated" by the FPGA,
and which Apple II slots should be accessed...

IE, FPGA has hard drive in slot 7, a flash RAM card, USB memory
stick, etc. Set the FPGA apple to deal with $c700 accesses
INTERNALLY.

The apple II that it is plugged into has a 5.25 drive in slot 6.

Set the FPGA to do $c600 accesses EXTERNALLY, IE through
the apple II slot.

It is a complete apple II replacement/accelerator/VGA card etc,
that can be plugged into an Apple II (to use apple II cards, drives,
keyboard, etc)

Put a small LCD on it, and a laptop or foldable keyboard, some
nicad batterys (cheap). Portable apple II (Accelerated, VGA output)
that can be plugged into the "docking station" in your REAL
apple II to use the old hardware.

(back to my VHDL tutorials)

Rich

[aiia...@gmail.com]

http://rich12345.tripod.com/ultii/index.html

part of my goal

[aiia...@gmail.com]

If any of the people playing with the Spartan3
know which pins on the Spartan should be routed
to which lines on the apple bus, I can make the
adaptor...

I haven't familiarized myself with the I/O pins
on the Spartan, but I read that some are more
suited for clocks, etc.

first person with a working solution gets the adaptor
for free :-)

Rich

[Mark McDougall]

aiia...@gmail.com wrote:

> The apple II screen is refreshed at 60hz. What does a VGA
> refresh at?

There's a range of valid frequencies, but 60Hz is one of them.

I've been thinking, there's probably a very simple way to do VGA output
with something as small as a PIC/AVR micro. You don't even need a frame
buffer to do simple VGA output, just a line buffer (or two).

Regards,
Mark

[Mark McDougall]

Michael J. Mahon wrote:

> Just out of curiosity, how much would it cost to "get your money
> back"? (I'm glad to hear it's OK not to get your time back.)

Well, that's going to depend on the product of course.

There's two big killers - getting the PCBs made in prototype quantities
(anything more than a few layers) - and getting 'major' components in
quantities smaller than 50, or in some cases, 1000. Sometimes you simply
*can't* get them (eg. video encoders) - others you pay a hefty premium.

Then there's the assembly - if you have parts with large pinouts you
really don't want to do them by hand, for time and quality reasons. BGA
etc you *can't* do by hand. So that adds big $$$ as well.

An example, a colleague & I designed a PCB with FPGA to emulate
cartridges for classic Nintendo consoles (still WIP). We got 6 PCBs
made, and bought only 2 FPGAs. Most other parts we scrounged for free,
but still paid over AUD$1K. And that's only 2! Not to mention many hours
of development.

There's absolutely no way such a niche, hobbyist market is going to
allow you to get your time back. Which is why you have to do it for the
love of it.

Regards,
Mark

[barana]

> To be honest, if you stuck a mid-range FPGA on a card with video, RAM and
> compact flash, you'd probably have enough capacity left over to implement
> the entire Apple II in the FPGA. I mean, look at the A2 - a board full of
> TTL and a 6502 - it's not that much logic for today's programmable logic
> devices.

> Some would be happy with a 'C-One' type setup, happy to use an apple
> emulated in hardware with modern peripherals such as keyboard and compact flash.

hermermherm.SIR!.

A C1 or any fpga ftm, does not 'emulate' it more acccurately 'clones'
or 'reimplements' HW :-p ;-)

[Michael J. Mahon]

aiia...@gmail.com wrote:
>>>the dual ported ram ?
>
>
>>8k RAM with two data/address busses, a select
>>line chooses which of these two to actually control
>>the RAM
>
>
> $400 to $800 = text OR lo-res screen 1kilobyte

|===> $7FF

> $800 to $1600 = text OR lo-res screen 2 1 kilobyte

|===> $BFF

> $2000 - $3FFF = hires screen 1 8 kilobytes
> $4000 - $4FFF = hires screen 2 8kilobytes

|===> $5FFF

AUX RAM copies are also needed for 80-column and DHR.

> 18k dual port RAM? It only has to be READ
> by the card, not written to (unless we make
> some hardware based sprite generator that
> stores into RAM as well as being displayed)
>
> Alex Freed wrote:
>
>
>>BTW there is no need for dual ported RAM: 500 nS out of every 1 mS 6502
>>does not acess the memory. That's how the normal Apple video works.
>>Using modern SRAM it is trivial to read 4 bytes in 500 nS (double scan
>>rate AND double hi-res or 80 columns).
>
>
> I understand the scheme, but will it work?
>
> Grabbing the video data off the bus (according to which address
> is being accessed by the CPU), and directly sending it to the
> VGA screen...

He's still talking about buffering it (as it must be) but
using a fast single ported SRAM to synthesize two (or more)
slower ports.

> The apple II screen is refreshed at 60hz. What does a VGA
> refresh at?

60Hz is fine.

> loop
> wait for video address on address bus
> get byte from databus
> send to VGA
> goto loop
>
> Won't the VGA screen refresh several times while the
> video generator in the apple II is accessing 1 frame?

Typically, at 60Hz and 2x15kHz, each line is displayed
twice, but any other asynchrony is optional.

[Michael J. Mahon]

Exactly. This is usually called a "scan doubler"--in this case
one specialized to the Apple II video.

[Michael J. Mahon]

Mark McDougall wrote:
> Michael J. Mahon wrote:
>
>> Just out of curiosity, how much would it cost to "get your money
>> back"? (I'm glad to hear it's OK not to get your time back.)
>
>
> Well, that's going to depend on the product of course.
>
> There's two big killers - getting the PCBs made in prototype quantities
> (anything more than a few layers) - and getting 'major' components in
> quantities smaller than 50, or in some cases, 1000. Sometimes you simply
> *can't* get them (eg. video encoders) - others you pay a hefty premium.
>
> Then there's the assembly - if you have parts with large pinouts you
> really don't want to do them by hand, for time and quality reasons. BGA
> etc you *can't* do by hand. So that adds big $$$ as well.
>
> An example, a colleague & I designed a PCB with FPGA to emulate
> cartridges for classic Nintendo consoles (still WIP). We got 6 PCBs
> made, and bought only 2 FPGAs. Most other parts we scrounged for free,
> but still paid over AUD$1K. And that's only 2! Not to mention many hours
> of development.

All good points. With newer, higher-density packaging, it's almost
a requirement to go at least 4-layer. I hadn't considered the "small
lot" problem for chips, but it certainly makes sense. And manually
soldering high-density surface-mount chips is a losing proposition.

> There's absolutely no way such a niche, hobbyist market is going to
> allow you to get your time back. Which is why you have to do it for the
> love of it.

Totally agree.

[Michael J. Mahon]

That's easy to say right up until you implement an Apple II peripheral
bus and fail to implement exactly the same setup/hold errors as are in
the real thing. List of incompatible cards to follow...

From a practical point of view, any reimplementation is an "emulation"
since the don't care and error states are unlikely to be a 100% match
to the original. (Ask Apple how many ][ and ][+ workable cards wouldn't
work in a //e, or //e workable cards in a IIgs.)

It's always a tradeoff...

[Mark McDougall]

Michael J. Mahon wrote:

> All good points. With newer, higher-density packaging, it's almost
> a requirement to go at least 4-layer. I hadn't considered the "small
> lot" problem for chips, but it certainly makes sense. And manually
> soldering high-density surface-mount chips is a losing proposition.

That's nothing - we're looking at doing a new board (for fun) with 672
pin FPGA and that will require 10 layers!

Regards,
Mark

[Mark McDougall]

barana wrote:

> hermermherm.SIR!.
>
> A C1 or any fpga ftm, does not 'emulate' it more acccurately 'clones'
> or 'reimplements' HW :-p ;-)

I beg to differ.

The definition of 'emulation':

"3. Computer Science. To imitate the function of (another system), as
by modifications to hardware or software that allow the imitating system
to accept the same data, execute the same programs, and achieve the same
results as the imitated system."

The C1 (for example) accepts the same data (ROM, software) and executes
the same programs (the fore-mentioned ROM, software) and achieves the
same results (video output, amongst others).

When 'cloning' hardware you're reproducing the same circuit at the gate
level. To some extent, most FPGA implementations do actually attempt to
do this. But only up to a point - there's PS/2 input, VGA output,
Compact Flash adapters etc which certainly aren't part of the original
design. And I know that *my* implementations are certainly 'emulations'
rather than 'clones' because I don't attempt to reproduce the same
circuit - but it achieves the same result!

Regards,
Mark

[Michael J. Mahon]

Sounds right.

It gets to be an expensive hobby, eh?

Now what will we do when we want to run a few dozen wafers and need
access to a .13 micron fab... ;-)

[BLuRry]

I saw a hobbiest site where guys used solder paste and a toaster oven
to take care of surface mount chips. Make it look really easy -- but I
don't think I want to stick expensive electronic components in a 450F
toaster oven. Not unless I was doing it for the sake of "science"
anyway (anyone seen a show called "Brainiac"?)

[Scott Alfter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In article <1140699387.4...@g44g2000cwa.googlegroups.com>,

That's a simplified version of how parts are normally installed in the
electronics industry. The trick is to ramp the temperature up and down on a
set schedule. One of the hardware guys in the office above me has a toaster
oven in his office, with a thermometer stuck in from the side, for exactly
this purpose. (I think he only uses it for BGA components on prototypes.
Everything else can be hand-soldered easily enough, and production
quantities get sent out for assembly.)

_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/ Top-posting!
\_^_/ rm -rf /bin/laden >What's the most annoying thing on Usenet?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD/fldVgTKos01OwkRAm6SAJ42WVdHTUWAVvIHgb2LFI0pt8oIrwCgg9sK
I5INyBUUiR6h1/QwNSe0c2Q=
=DwUk
-----END PGP SIGNATURE-----