Rendering pictures on the Altair

[Eightbitswide]

I've created a simple picture viewer for MBASIC.

It uses the FabGL serial terminal for output of 64 colors.

It's SLOW. :)  Takes about 30+ minutes to render the image from a .PPM file. (Portable Pix Map Image)

Here's a couple images that I've converted down to 64 colors.

I'll post some code when I get it cleaned up. At the moment I've written just enough code to prove the concept works.

-8b

[Charley Jones]

Wow

Sent from my iPhone 12pm!

Charley Jones, PMP

On Oct 25, 2022, at 9:05 AM, Eightbitswide <jeffl...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "Altair-Duino" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altair-duino...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/dcd305a2-df94-467d-96eb-bed237ca2a8cn%40googlegroups.com.

[villa...@gmail.com]

Glad you've got the Fabgl stuff operational. Be interested to see your code when ready.

[Walt Perko]

Hi, 

What is the final resolution of those pictures?  

I think the photos would probably look the same a DAZZLER ... in color, but much sharper in black and white.  

[Eightbitswide]

These are 200x128, but I can render 512x384.  I wouldn't recommend it as running from basic it takes 30 mins to draw them at this smaller size.  I will compile the final code and see if I can get a little more speed.

8b

[fridtjof.ma...@gmail.com]

If you compile the code with BASCOM, you can get a speed-up. For even more speed-up, 

https://github.com/ratboy666/apu

This allows use of the AM9511 APU with FORTRAN-80 and BASIC-80

But... this needs AM9511 support:

https://github.com/ratboy666/am9511

allows the AM9511 to be emulated. I have never tried this on my Altair-Duino... But it should work.

(this is already in Udo Monk's z80pack). The APU support has been tested against the real AM9511,

and tested against the emulator.

It may even be possible to put a real AM9511 on the Altair-Duino expansion bus --but, note, this chip

sucks a lot of power (4W or so, I think) and gets really hot.

Fred Weigel

[fridtjof.ma...@gmail.com]

APU accelerates the following:

INTEGER * INTEGER, INTEGER / INTEGER (and the same with 32 bit integer), 4 byte (single precision) floating point but NOT double precision. Included a paper by Dekker (from 1971) that gives a technique for using FLOAT-FLOAT to accelerate DOUBLE. The AM9511 doe not have double precision floats, only 16 and 32 bit integer and 32 bit float. 

Let me know if you incorporate AM9511 into the Altair-Duino... And also any experiences with the APU integration library.

Thanks

Fred Weigel

[Eightbitswide]

Got most of the code working correctly.  Will attempt a compile tonight.

[Eightbitswide]

Compiled code, source, and example photos are posted here.

https://github.com/eightbitswide/ppmview

8b

[fridtjof.ma...@gmail.com]

8b

Thanks for publishing! Some comments:

1 - Good work!

2 - use WIDTH 255. If you do that, line 80 can be removed.

3 - DEFINT can be your friend with the compiler. DEFINT A-Z to make all variables

integer. This has much more impact on the compiler than on the interpreter.

4 - I initially thought that the MBASIC code was doing colour reduction. Ignore my comments

about AM9511 use (that would allow colour reduction).

5 - character extraction is expensive. You may wish to consider the following:

S$="ABC"

N=VARPTR(S$)

PRINT PEEK(N)

3

P=PEEK(N+1)+PEEK(N+2)*256

PRINT PEEK(P)

65

Notice that as long as we do NOT do anything with strings, S$ is not moved. The PEEK(N) gives

us the length of S$ (3 characters) and the P=PEEK... line gets a pointer to the string data itself.

65 is the ASCII value of "A" (the first character of S$). P+1 and P+2 are the other two characters

in the string. Using this, you can avoid mid-string extraction, and creation of string overhead.

Combine with DEFINT, and should get a good speed-up.

NOTE NOTE NOTE: I have not actually done this... just making some comments about the program,

how to make it faster, whilst leaving it in MBASIC. You may like my code in

https://github.com/ratboy666/halfg

where I note that modern terminals (probably FabGL as well -- not sure), actually use UTF-8. And,

UTF characters include 2x2 graphic cell. halfg exploits that to have a 160x48 drawing grid.

Note that the "advanced" optimizations have also NOT been done in halfg -- I left it as a fun

puzzle for the reader.

Fred Weigel

[Eightbitswide]

Fred,

Added DEFINT A-Z to my source.  Testing it now.  It does appear to speed things up.

Not sure what you meant in WIDTH 255.  My current line 80 is a REM statement.

8b

[fridtjof.ma...@gmail.com]

8b

Sorry for the "line 80". I meant:

560 PRINT CHR$(27)+"[H";

Remove that line, and add a line

105 WIDTH 255

In MBASIC 5.21 (and BASCOM), setting WIDTH to 255 eliminates the automatic CR/LF

Note that Microsoft BASIC for Altair does not do this -- it is too old. I apologize -- I don't

know where I pulled 80 from (probably my a**).

If I get cycles, I may (desire, may not hav time) try to make this do sixel output instead of FabGL.

I am happy that DEFINT worked! It should work at its best with BASCOM.

Fred Weigel.

[villa...@gmail.com]

That worked well thank you 8b! To get the .ppm file, - is that using GIMP with a JPEG file i/p and converting direct to .ppm (not used GIMP before)?
Colin

[Tom Lake]

Do you know where we who live in the USA can get the FabGL terminal?

[villa...@gmail.com]

Don't know how easy Tindie is for you Tom OR direct from Aliexpress e.g  LILYGO® TTGO VGA V1.4 Controller

https://www.tindie.com/search/?q=FabGL+termina

The software is all from FabGL and programmed using Arduino IDE - simples!!!

[Tom Lake]

Once you load the file into GIMP, you then choose File, then Export As... and change the file's extension to .PPM.

When you click the Export button, a little window will appear, "Export Image as PNM" with two options, Raw and ASCII.

Choose the second option, ASCII, and click the Export button. The process will only take a few seconds and your PPM file is ready to use.

[Charley Jones]

Love seeing all of this.  Integer math is, by definition, always faster. Especially anything that fits in a register.   Glad to see all the work with FabGL.  Simply amazing. 

Sent from my iPhone 12pm!

Charley Jones, PMP

On Oct 28, 2022, at 4:00 AM, Tom Lake <tl...@twcny.rr.com> wrote:

Once you load the file into GIMP, you then choose File, then Export As... and change the file's extension to .PPM.

--

You received this message because you are subscribed to the Google Groups "Altair-Duino" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altair-duino...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/add31124-f0ac-4a71-a1f5-abac9cf930cen%40googlegroups.com.

[Eightbitswide]

I ordered mine from LILYGO on Aliexpress. 

(Link to seller: https://www.aliexpress.us/item/2251832855287283.html?spm=a2g0o.order_list.0.0.3bd41802xwb8Dd&gatewayAdapt=glo2usa&_randl_shipto=U)

It takes around two+ weeks to get them, so being the inpatient person I am, I also ordered a couple of ESP32's from Amazon.

(Link: https://www.amazon.com/dp/B09XDMVS9N?psc=1&ref=ppx_yo2ov_dt_b_product_details)

I approximated the VGA circuit by combining resistors I had in my shop and split the TTL TX line into the ESP32.

I was never able to successfully replicate the PS2 keyboard circuit on mine, but really didn't need it as I've already built a USB keyboard to TTL serial interface from something else.   Sometime this weekend I'll get the pins soldered in and try out the LILYGO product itself.

8b

[Eightbitswide]

John,

Hope this image will help.

On Sunday, October 30, 2022 at 1:27:06 PM UTC-4 John Galt wrote:

have an issue making files with Gimp. my Photoshop doesn't have a ascii output option.

in gimp when i export as PPM and ASCII keeping it to 200pixel width for the sake of speed when i try to load it into the View it just bombs back to the prompt.

what is the procedure for creating the proper PPM image step by step?

[Eightbitswide]

The Line Ending note should not apply to you. 

I noticed that the Linux text editor needed this when sending BASIC or .PPM files to the unit.

On Sunday, October 30, 2022 at 2:38:45 PM UTC-4 John Galt wrote:

ah thank you the Note about the Line endings is the key as i'm in windows 10.

[Walt Perko]

Hi, 

I hate Thingiverse.com.  Before you can download a project, you have to go through "Donataon" menus/pages to get to the parts ... that's why I stopped posting my designs there.  Now I post on PinShape.com ... it's easier, faster and people can get to the part files without screwing around with "Donation" pages.  The parts are either FREE or you pay a buck or two and get to the files 10x quicker.  

On Sunday, October 30, 2022 at 12:03:21 PM UTC-7 John Galt wrote:

i should give a note to anybody buying the VGA32 V1.4 boards. the GPIO connection silkscreen on the PCB top is backwards. 

Use the silkscreen information on the PCB bottom to setup your connections.

there is no information giving on websites about this error. took me a while to figure it out why my serial connection refused to work.

there is a nice case here if you can 3d print.

https://www.thingiverse.com/thing:4790919

video of it used on a IMSAI 8080

https://www.youtube.com/watch?v=LOhmlOyUw4w&ab_channel=AmateurTinkering

warning the video does not show the wiring which was annoying. just keep in mind that top side information for the pin outs is wrong.

On Sunday, October 30, 2022 at 2:55:10 PM UTC-4 John Galt wrote:

i just converted my PPM in ConTEXTv0_986 to append "CR LF" as Gimp in windows was only putting "LF" at the end of each line.

under windows using "ConTEXT" its Tools -> convert text to -> DOS(CRLF) i double checked in NotePad++ the change occurred.

loaded to my altair so far its working.

[Walt Perko]

Hi, 

While fighting with Thingaverse and NOT being able to download the little box parts to 3D print ... I started looking elsewhere for the files and ran into this page;  

https://www.hackster.io/news/fabrizio-di-vittorio-s-fabgl-project-gets-a-serial-terminal-board-with-ttl-and-rs232-connectivity-15465c850f07

I hate Thingaverse ... no matter what I do, I get the pop-up window requiring a donation before I can get to a file to download!  That's why I stopped posting my stuff there, for all the complaints I got from people wanting to download the stuff I posted for FREE!  That's why I post my stuff on PinShape.com ... much easier to upload, and much easier to download!  

Too bad the video didn't show the connections from the TTL to RS-232 adapter to the TTGO VGA32 Serial Terminal Emulator board.  

The three things I need:  Tx to Rx, Rx to Tx and .STL files.  

.

On Sunday, October 30, 2022 at 12:03:21 PM UTC-7 John Galt wrote:

i should give a note to anybody buying the VGA32 V1.4 boards. the GPIO connection silkscreen on the PCB top is backwards. 

Use the silkscreen information on the PCB bottom to setup your connections.

there is no information giving on websites about this error. took me a while to figure it out why my serial connection refused to work.

there is a nice case here if you can 3d print.

https://www.thingiverse.com/thing:4790919

video of it used on a IMSAI 8080

https://www.youtube.com/watch?v=LOhmlOyUw4w&ab_channel=AmateurTinkering

warning the video does not show the wiring which was annoying. just keep in mind that top side information for the pin outs is wrong.

On Sunday, October 30, 2022 at 2:55:10 PM UTC-4 John Galt wrote:

i just converted my PPM in ConTEXTv0_986 to append "CR LF" as Gimp in windows was only putting "LF" at the end of each line.

under windows using "ConTEXT" its Tools -> convert text to -> DOS(CRLF) i double checked in NotePad++ the change occurred.

loaded to my altair so far its working.

On Sunday, October 30, 2022 at 2:42:37 PM UTC-4 Eightbitswide wrote:

[Walt Perko]

Hi, 

I'm designing a slightly larger case that has room for top to bottom 3mm bolts to bolt the case together, but also allows for hanging on the back of any LCD monitor.  

.  

On Saturday, November 19, 2022 at 8:46:16 PM UTC-8 John Galt wrote:

its really not a problem with thingiverse.

take  https://www.thingiverse.com/thing:4790919 once more

if you click on "download all" that is the first mistake.

go to "thing files" in that example which shows 2.

click on the individual stl files. "download" NOT "download all"

next you should have a bunch of ad blockers installed on the browser of your choice and configure them as needed.

these are the two files for the case you can download them from here.

the case isn't "perfect" you have to shave some of the lip in the upper case that rides against the VGA connector and the PS/2 keyboard and mouse ports, so it does not bend the VGA32 board but the case is nice

the round hole in the case is if you want to install a power switch to cut the 232 off and reset it. the VGA32 also has a reset button that is not accessible through the case.

i used a switched power supply for the vga32 anyway so if it locks up (which it has) i just turn my power switch on and off for it and reset everything that way without power cycling the altair.

[Walt Perko]

Hi, 

New case design almost done ... lid is printing ... 

[Walt Perko]

Hi, 

Last thing I need is to know which PINs on the TTGO are Tx and Rx ???  

On my board the PINs are labeled;  

 3V3 GND IO39 IO34

   °        °       °        °

   °        °       °        °

IO12 IO14 IO13 IO2

.

[Walt Perko]

Hi, 

It looks like this is what you have in the photo:  

IO34 IO39 GND  3V3 

 Tx   NC  GND  +3V

 Rx   NC  NC   NC

IO2 IO13 IO14 IO12 

On Sunday, November 20, 2022 at 3:54:01 PM UTC-8 John Galt wrote:

[Walt Perko]

Hi, 

Yeah, that part I know ... but that's why I set Tx to IO34 and Rx to IO2 ... if that's how it is on your board.  It's not easy to see exactly in the photo.  

.

On Sunday, November 20, 2022 at 6:18:18 PM UTC-8 John Galt wrote:

the silk screen on the vga32 top is wrong do not follow it.

its backwards follow the silk screen on the bottom of the PCB.

[Walt Perko]

Hi, 

Finished the build after digging out a micro toggle switch to install ... 

The part files are here ... FREE for downloading:  https://pinshape.com/items/113511-3d-printed-vga32-fabgl-ttgo-ttl-to-rs-232-adapter-box  

.

[Tom Lake]

On the one I just got, it looks like the info on the top is correct and the info on bottom is backwards! 

GND and 3V3 should be the connections away from the edge of the board, no?

View from top:

3V3 GND IO39 IO34

IO12 IO14 IO13 IO2         

_______Edge of board_________

On Sunday, October 30, 2022 at 3:03:21 PM UTC-4 John Galt wrote:

i should give a note to anybody buying the VGA32 V1.4 boards. the GPIO connection silkscreen on the PCB top is backwards. 

Use the silkscreen information on the PCB bottom to setup your connections.

there is no information giving on websites about this error. took me a while to figure it out why my serial connection refused to work.

there is a nice case here if you can 3d print.

https://www.thingiverse.com/thing:4790919

video of it used on a IMSAI 8080

https://www.youtube.com/watch?v=LOhmlOyUw4w&ab_channel=AmateurTinkering

warning the video does not show the wiring which was annoying. just keep in mind that top side information for the pin outs is wrong.

On Sunday, October 30, 2022 at 2:55:10 PM UTC-4 John Galt wrote:

i just converted my PPM in ConTEXTv0_986 to append "CR LF" as Gimp in windows was only putting "LF" at the end of each line.

under windows using "ConTEXT" its Tools -> convert text to -> DOS(CRLF) i double checked in NotePad++ the change occurred.

loaded to my altair so far its working.

On Sunday, October 30, 2022 at 2:42:37 PM UTC-4 Eightbitswide wrote:

[Walt Perko]

Hi, 

The Pro's and Con's ... 

Pro ... the terminal works well with my Altair 8800c, I like the hot config menus so I don't have to connect to my PC via the USB cable, but just power the terminal with the USB into a USB ac adapter.  

The Con ... 

I tried the Maurer and other graphic programs that work so well with the Geoff Graham enhanced terminals, the just display numbers when I had it selected to VT-52  ???  

I thought this was supposed to be compatible with those graphics ??? 

[Walt Perko]

Hi, 

That's the trick ... new versions of the graphics programs for the FabGL software.  

I'm not sure my brain can wrap around the changes to make them.  Dyslexia is a tough obstacle to hurdle with the code.  That's a huge part of why I'm not really a programmer.  

.  

On Monday, November 21, 2022 at 8:35:25 PM UTC-8 John Galt wrote:

No its not compatible nobody ever said it was.

you could create a new terminal that emulates the geoff.

The Geoff Terminal uses its own graphics escape codes.

The VGA32 has its own different Graphics escape codes. 

The difference is the VGA32 graphics functions are more numerous, powerful and in color. Since it supports Color then it can support ANSI Color terminal.

It can also emulate a bunch of different serial terminals from the ADM to the Kaypro which use their own escape codes and it has much better VT52/100 support as compared to the Geoff.

This allows you to use kaypro or ADM programs where you cannot change the escape codes that are hard coded into the source. The better VT100 support makes programs easier to use.

as for the little graphing algos that were ported to the Geoff. you can simply change the Escape Code and port them to the VGA32 and extend there functionality with color.

[villa...@gmail.com]

Very impressive John, that's a great achievement.

Have my 9pin OKI Microline 320 functional and hooked up to the Altair so maybe following in your footsteps!!!

Colin

On Sunday, 4 December 2022 at 02:03:09 UTC John Galt wrote:

it will only let me attach 1 or 2 photos at a time

On Saturday, December 3, 2022 at 9:02:22 PM UTC-5 John Galt wrote:

slowly adding features:

* 17 levels of grey support 72x72 dpi to the printer in 8x8 Bayer pattern dithering. (will get around to increasing it to 144x144 with 4x4 Bayer)

 

* Dazzler support up to 64x64 in 15 levels of grey. (128x128 monochrome in future)

* you can direct output to Terminal, dazzler or printer.

* Brightness control for the printer output. might add same support for dazzler to correct images.

* Added a RGB to Grey scale convertor for the printer and dazzler support.

[villa...@gmail.com]

Very impressive results and I guess a lot of work to achieve them. I think I would get through too many ribbons doing this!!!

On Saturday, 17 December 2022 at 06:18:36 UTC John Galt wrote:

played with traditional grey level conversion verse HSL made no difference.

the good news is I'm getting the output correctly as i'm matching existing examples.

the lighter color is due to having to refill the ribbon ink again.

On Friday, December 16, 2022 at 9:15:09 PM UTC-5 John Galt wrote:

side by side of resolution difference.

On Friday, December 16, 2022 at 2:30:47 AM UTC-5 John Galt wrote:

first test of my high resolution printer output.

the 72x72 picture in the previous post was using a 8x8 dot to generate 16 levels of grey. the new one has now doubled to 144x144 using a 4x4 dot representing the same 16 levels of grey.

the upshot is now the same picture takes half the space. 

now you can double the resolution in the same space.

On Sunday, December 4, 2022 at 11:11:18 AM UTC-5 John Galt wrote:

part of the problem is the available ram and how slow disk access is. true dither algos require reading in a large part of the photo then doing quite a bit of calculations based on surrounding pixels and having to keep track of where a dot is currently positioned. after looking at options nothing was earth shattering or much better then the way i tried it. K.I.S.S. gives the best bag for the buck, plus with the dot matrix resolution the smallest possible grey scale you can make is 4x4 giving you enough simulated grey levels. 

[Eightbitswide]

Any chance you could post a .zip of the files themselves?  I'm trying to export them using CPMTools, and it can't make heads or tails of the image.

Thanks

8b

On Tuesday, February 14, 2023 at 7:37:49 PM UTC-5 John Galt wrote:

i have been slammed with work and other things and made no real progress the last 3 weeks.

So I'm going to just release what i have and let everyone try it out.

included on this 330kb disk image, there are a few PPM test files to mess around with. start with the smallest files so if you have an issue it will not take hours to find out.

listed okidata printers are supported, place the printer into EPSON mode you can test with the small target ppm files.

you will need a harddrive image to copy everything onto as PPM is uncompressed and even tiny images will be over 5megs in size.

many images larger then 200x200 can take several hours to render or even longer to print.

the small files i have included you can get through fast for playing around and testing.

have fun.

On Saturday, January 28, 2023 at 12:27:37 AM UTC-5 John Galt wrote:

you have to love 3d printing...

TPEE makes decent tractor feed belts.

On Friday, January 27, 2023 at 2:22:32 PM UTC-5 John Galt wrote:

running into setbacks. :(

In addition i had parts start to fail on the 320 Printer requiring some 3d print replacements.

On Friday, January 20, 2023 at 1:51:01 PM UTC-5 John Galt wrote:

I'm so unhappy with the 320 printer's tractor feed setup I'm hoping to upgrade it with a top pull tractor feeder to stabilize the paper. the 192 printer has a top pull option that works REALLY well, so hopefully this improves the 320 also.

On Wednesday, January 18, 2023 at 10:12:36 PM UTC-5 John Galt wrote:

i'm hoping to drop a nice little program soon

PPM VIEW 2 Alpha

it will give you the ability to:

dither your ppm image file to the screen or not to save time.

printer output via floyd steinberg dithering as this will allow the printer resolution to match the max screen resolution of 64 color mode.

you will be able to invert output to the printer and adjust brightness of the output if needed.

you can process any ppm file through ppm view 2. if you have generated a math plot and saved it as a proper ppm file then output will be a breeze.

its been a lot of work and now i'm bug testing and adding some error checking to make it a little robust.

On Sunday, January 15, 2023 at 4:08:05 PM UTC-5 John Galt wrote:

I'm pretty happy with this result. 

i had to write a bunch of code to work around the firmware issues with okidata 9 pin printers.

its working much better then it ever did with my 192 printer.

the worst case is when you have two horizontal lines occur at dot position 1 and 4 which is a escape code "9". trying to use "9" results in the printer going nuts and printing a dot at position 1 four times for each time you try and use "9" so since "9" is made up of position 1 or 4 (1) or (8) (8+1)=9 i decided to have it flip flop between 1 or 4 so that it would print something. if you were plotting lines its either 1 line missing or half tone both lines so you can still see the data.

since i had to decide to out put one way or the other flip flopping and i didn't want to start massive pixel testing algos i had to barrow a dot from one side or the other. thus 818 or 181 where you can see one dot missing from the cross on the left or right side.

its a really horrible bug in these printers and it cased so much work around code its ridiculous.

the emulation ML on the okidata 320 did fix 2 additional bugs with dot 1 and 4. when you used dot 4 at any time the printer head incremented the wrong amount, multiple 4 dots would stretch the output of the row. dot 1 would also increment the head stretching the output of the row but at half the distance of 4. so when you used 1 or 4 as a replacement for 9 this would shift the entire row.

really nasty bug in APA graphics mode for those 3 dot combinations.

lenna at 72x72 dpi came out nicely, now i can run a longer test with my workaround and see the result.

 

On Wednesday, January 11, 2023 at 10:54:39 PM UTC-5 John Galt wrote:

The IBM version of the Okidata 192 came in today. it needed some minor repairs and is in fact in excellent shape.

i serviced the machine and confirmed it uses the IBM Graphics commands similar to the 320T however not everything was supported.

i found some information to fill in the IBM language gaps and found that it basically uses a hybrid of EPSON language.

i confirmed the same bug is present on the later Okidata 192 IBM firmware as on the Okidata 192 ML firmware and the same problem is present with the Okidata 320T and i would guess all 9pin printer models as this is a problem at the very lowest level of the firmware and most likely this same bug was copied from the 180 printer series that first introduced Graphics mode all the way through the later 9pin printers. the 24 pin printers work differently and do not have the same graphics mode as the 9 pin printers.

i confirmed that the firmware workaround does in fact work in all 3 modes of the 320T printer. I also confirmed that Okidata's own graphics code in the manuals will not work properly. 

i put the 320T back on the bench and went back to my EPSON version of the printer driver and put in my Patch and i'm running tests to see how bad it is.

the IBM 192 firmware does not have a 72X72DPI mode like the ML 192. but the Epson 320 printer line does, it only support 72x72DPI in EPSON mode.

errors in these tests are the firmware bug, corrected versions use the work around but its not perfect. 

On Wednesday, January 11, 2023 at 3:01:31 AM UTC-5 John Galt wrote:

Well bad news I recieved a mint condition okidata 320t printer and recoded everything to work with Epson mode.

First I tried ML emulation and it had the same bugs as the okidata 192 printer it fails okidata’s own test in the manual for the 320t

IBM mode I could not find all the documentation I needed to test so I dropped it.

Back to epson mode…

I started running my printer torture tests and everything was looking good at first. My 3rd test failed horribly showing that the firmware bugs in all these 9 pin printers was never fixed. They wrote around the problem with ibm and epson modes but at the core it’s completely flawed. My 3rd test failed even worse then my okidata 192

I then ran a dither test a simple one and it completely failed compared to the 192

At this point I have to get a real epson 9 pin printer and run the code on that machine and see what happens.

Really disappointed I spend 8 hours on this tonight and I liked the 320 printer too

On Saturday, January 7, 2023 at 10:47:02 PM UTC-5 John Galt wrote:

maybe some interesting news:

i was donated a later Okidata 192 printer that has the later IBM Firmware 1.01 from 1985. The version i have is OKI 2.02 from 1984.

Apparently this firmware is fixed and also uses the updated APA Graphics language as the 320 series of printers and the later 300 series printers

 

later 192/193 printers were updated and have the newer manual and a special "IBM compatible printer" sticker placed on the box, the manual and on the backside of the printer under the parallel port.

I'm going to the 320 printer but i will be swapping my 192 firmware and then see what happens with compatibility and if the bug was really fixed or not.

from what i can tell with the 1984 firmware APA Graphics bug:

you have a column of 8 dots out of the 9 that are used for APA Graphics mode.

Dot  Value

1  = 1

2  = 2

3 =  4

4 =  8 

5 = 16

6 = 32

7 = 64

8 =128

if you tell the printer to print 2 dots at 1 and 4 which is the character "9" you get a single dot at position 4 that cycles 4 times.

if you tell the printer to print 1 dot at position 1 or 4 it will print the dot but then the carriage moves to the next position incorrectly.

the carriage command for a backspace does not work either.

the more dots you print in position 1 or 4 the more stretched your output becomes as it seems to go into 60DPI mode when its suppose to be in 72DPI mode.

i tried making a 1 and 4 dot using 1 or 4 with a backspace and learned that didn't work either. and i could not reposition the print head as that command doesn't seem to work either for a home command.

my Bayer 8x8 and 4x4 matrix avoided single dots  or a double dot in 1 or 4 position, by a happy accident and thus i did not encounter the bug. a 2x2 would have the bugs occur.

 

On Saturday, January 7, 2023 at 9:45:26 AM UTC-5 John Galt wrote:

i made some changes then ran this last test using the okidata192. the last line that is elongated on the printout is part of the firmware issue i cannot patch around. each row that does not line up on the right edge has a firmware error in it as well.

i'll be changing over to the okidata 320T printer which also uses epson commands for graphics.

i'm wondering if i should add some addition export options. 1) output a pre-dithered ppm file so once you process a image it will export it as a ppm file allowing for fast re-display. 2) output a pre-dithered printer output file in much the same way.

this will allow for reprinting a file in minutes not hours. 

its never ending; you can keep adding features until the ram runs out.

On Friday, January 6, 2023 at 6:05:33 PM UTC-5 John Galt wrote:

this test ran for 12 hours:

I'm pleased with the outcome. there was some firmware issues as i knew would occur, some program refinement needed as well.

On Friday, January 6, 2023 at 12:26:10 AM UTC-5 John Galt wrote:

the Altair 200x118 test

old on left with the Firmware issues. new on right with Firmware workaround.

On Friday, January 6, 2023 at 12:16:56 AM UTC-5 John Galt wrote:

i felt a little better tonight so i started messing with my Okidata 192 again.

I made a Kludge work around for the firmware bugs.

Old on the left, new with firmware workaround on right. its not perfect but removes some of the worst issues.

I added a brightness control for the printer dither algo as well, so the right image was brightened about 8% compared to the left.

I have a okidata 320 turbo coming my way to replace my okidata 192 with the firmware problems.

it was not worth attempting to update my 192 as it would still have very buggy firmware the 190 model line was riddled with problems.

the okidata 320 will have the updated graphics language to play with.

 

some larger tests are on the way.

On Friday, December 30, 2022 at 12:35:06 PM UTC-5 John Galt wrote:

this is the result of 144x144 resolution with the firmware errors visible. since 1x1 level of control is buggy due to the infinite combinations the best would be a 2x2 bayer for max resolution with dithering giving 6 levels of gray control which would allow 288 resolution. 1x1 allowed 576dpi. with the lower combination of possible pixel placement it might be possible to have control over the firmware problems with my printer.

it means the minimum line thickness will always be 2 dots

On Friday, December 30, 2022 at 2:30:20 AM UTC-5 John Galt wrote:

here are the prints where the printer firmware caused problems. you can see without the firmware getting in the way these would have been quite good for the tiny resolution.

On Friday, December 30, 2022 at 2:08:32 AM UTC-5 John Galt wrote:

here is a maddening situation.

I've have been working on printer dithering code for my okidata 192 printer.

I've have been shooting out test prints and have been chasing bugs that didn't exist.

 

apparently the okidata 192 has some major firmware bugs. my unit is a pre 1985 with firmware 2.01

     in June 1985 okidata completely revamped the printer addressing some massive graphics firmware bugs.

i ran right into them.

the 1985 manual will not even work with the 1984 version at all in 1985 okidata removed the 72x72 dot mode completely which is the mode i'm using and had most of the firmware bugs.

certain sequences of binary data next to each other makes the printer flip out.

when i coded the Bayer 4x4 and 8x8 tables i happened to avoid the bugs in the firmware, however using the printer in 1x1 mode brings out these bugs.

these bugs will not allow certain sequences of dots to be next to each other. if you happen to have these dots next to each other the printer flips out and outputs a line of 4 dots for no reason then tries to recover where it left off, but now its 4 dots from where it should have been with erroneous data.

next my printer kept crashing and going into 7bit mode when it was suppose to be in 8 bit mode. this caused the dropping of every 8th line of data being sent to the printer as it would just ignore it.

you can imagine I'm going through my code over and over and can not find the problem and it only revealed itself as i started making little test images to output with specific shapes.

if i want to continue I'm going to have to get a better dot matrix printer.

 

On Tuesday, December 27, 2022 at 9:59:18 PM UTC-5 John Galt wrote:

CUBS.PPM

BEFORE:

AFTER:

On Tuesday, December 27, 2022 at 3:35:45 PM UTC-5 John Galt wrote:

here is the ALTAIR.PPM redrawn with dither.

before:

after:

On Tuesday, December 27, 2022 at 2:10:37 PM UTC-5 John Galt wrote:

this also adds a ton of extra time to display the photo.

you have to buffer 2 full rows of the photo to be dithered, apply all the weights, draw the first row, bump the second row to the first row then run through the loop again. 

On Tuesday, December 27, 2022 at 2:07:22 PM UTC-5 John Galt wrote:

ok got the Floyd-Steinberg dither going.

before:

here you can see the results.

its hard to capture with my camera but it looks really good

[Jeff Ledger]

John,

Nicely done!!  The time to render is mostly disk access time so it runs about the the same at 8mhz as it does on the AltairDue.

Any chance you'll share your .BAS file?   Also, do you mind if I add the files to the github for PPMVIEW with a note that you authored the changes?

8b

On Tue, Feb 14, 2023 at 10:46 PM John Galt <furba...@gmail.com> wrote:

oh yhea i also put paku64 and paku128 on there little dazzler demos i made.

On Tuesday, February 14, 2023 at 10:44:50 PM UTC-5 John Galt wrote:

altairdsk -d disk29.dsk 

would list the contents of the disk

che.com is a dazzler program you can try out.

i made a version of the viewer for the dazzler but i didn't finish adding features to it.

On Tuesday, February 14, 2023 at 10:43:02 PM UTC-5 John Galt wrote:

the command would be 

altairdsk -g -t disk29.dsk ppmview2.com

that would grab the app

altairdsk -g -t disk29.dsk brun.com 

would grab the rest you need.

On Tuesday, February 14, 2023 at 10:38:12 PM UTC-5 John Galt wrote:

use this instead

https://github.com/phatchman/altair_tools

the disk is all preped since it uses bascom and you need brun to make it work.

--
You received this message because you are subscribed to a topic in the Google Groups "Altair-Duino" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/altair-duino/ajHnHReFGg4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to altair-duino...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/8a59a800-1357-40d6-9680-d332ec1bbcb5n%40googlegroups.com.