VBXE 2

[flashjazzcat]

Speaking of tedious tasks, I fired up the Atari again this morning and the picture was jumping all over the place. The LG seems to take unpredictable mood swings when it comes to syncing with VBXE. Back to the drawing board...

[Rybags]

I think I've found a couple of bugs in VBXE.

 

 

Firstly... doing a quick DLI to change PRIOR to $80 and back to $00 (to invoke the mode where hires turns to multicolour using PF0 for background and PF1-PF3 for Colours 1-3) before the start of standard display... for some weird reason the display "retracts" backwards - at first I thought maybe it was due to my colour combinations but even setting COLBAK, PF2 and PF0 to the same colour sees the problem remaining.

 

Secondly... I changed the DLI such that it stores $00 to PRIOR in both instances - so no mode change should occur... but it still does occur.

 

Thirdly, change the initial PRIOR change to $40 - now I get a shimmering effect.

The shimmering has stopped... but replaced by the offset "retracted" effect.

 

I'm doing this in the Atari Assembler/Editor, just default E: screen with one DLI enabled.

The code is as follows:

 

$4000 pha
tya
pha
ldy #6
sta $d40a
$4008 lda #$80
sta $d40a
sta $d01b
lda #$00
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
sta $d01b
dey
bne $4008
pla
tay
pla
rti

 

Also, try changing the byte at $4009 (initial PRIOR value for each scanline... I'm 99% sure that on standard hardware it should revert to normal text.

[Rybags]

Seems there's a bug with PRIOR handling... try this on VBXE.

 

10 POKE 53275,0:GOTO 10

 

Same deal whether the value is 0, 1, 16, 32 etc.

[+bob1200xl]

OK - I'm done with the install, but I can't hook up to RGB with a YPbPr monitor. The normal, Atari video is OK. The RGB outputs look like 15khz sawtooth waves, none of which show sync. I can't sync my YPrPb inputs with the 15khz Atari sync - can't see what the VBXE output looks like. The AVR LED is on solid. The FPGA LED usually blinks at 1hz.

 

It's not so simple to convert RGB to YPbPr... got any ideas?

 

 

Bob

 

 

 

Tell You what Bob

I'll do RGB->YPbPr converter, and You'll install that damn VBXE into Your computer

Do we have a deal?

[candle]

Bob, that perfectly allright

 

now run FC.COM from VBXE package, and change boot core to one of FX cores

 

Your VBXE was shipped with test core set as bootable - this was the only way i could test it without completly assembling antic connector

[candle]

converting the RGB to YPbPr is quite simple in analog domain, i've already bought the parts for it, now i need to sqeeze some time to do it

basically its done by three summing amps with noninverting configuration

[peteym5]

(bump)

 

I got some new 40 pin sockets and managed to patch one 130XE Main Board and it is not working properly.. Just see a black screen with some white bars flashing across. I know it is a loose connection but I am not presently equipped to figure exactly where. Considering sending it to someone and have them do testing. Prefer somewhere on the Eastern United States on here who can do such repairs? Did a few re-solders already and is not making a difference. This is a cheap 130XE I got from Ebay and was not working right in the first place. I only pulled out like 2 traces, got much better at it. To do a more detailed job would require me to desolder parts and run a greater risk of damaging the board.

 

I have a 2nd 130XE board which has many more traces pulled out that I am slowly putting back together. That is the one I wrecked severly before I figured out how to remove ICs without breaking chips or pulling out traces. I am cutting up an old IDE cable for the patches that after you strip the ends off, fits inside the holes with the pins neatly and can be soldered together without a problem.

 

What I learned is after you desolder from the top, you have to go through again from the bottom with the soldering iron and solder sucker. That makes sure no traces get pulled.

[electron]

I think I've found a couple of bugs in VBXE.

 

 

Firstly... doing a quick DLI to change PRIOR to $80 and back to $00 (to invoke the mode where hires turns to multicolour using PF0 for background and PF1-PF3 for Colours 1-3) before the start of standard display... for some weird reason the display "retracts" backwards - at first I thought maybe it was due to my colour combinations but even setting COLBAK, PF2 and PF0 to the same colour sees the problem remaining.

 

Secondly... I changed the DLI such that it stores $00 to PRIOR in both instances - so no mode change should occur... but it still does occur.

 

Thirdly, change the initial PRIOR change to $40 - now I get a shimmering effect.

The shimmering has stopped... but replaced by the offset "retracted" effect.

 

I'm doing this in the Atari Assembler/Editor, just default E: screen with one DLI enabled.

The code is as follows:

 

$4000 pha
tya
pha
ldy #6
sta $d40a
$4008 lda #$80
sta $d40a
sta $d01b
lda #$00
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
sta $d01b
dey
bne $4008
pla
tay
pla
rti

 

Also, try changing the byte at $4009 (initial PRIOR value for each scanline... I'm 99% sure that on standard hardware it should revert to normal text.

 

Rybags, can you prepare a binary DOS loadable COM file with this test in its different variants as you described above ?

 

Thank you in advance.

[+bob1200xl]

I don't think so...

 

The component inputs will display 480i or 480p, but regardless, the Hsync pulses during VBLANK (and for some time there after) have to be 31us. It doesn't look like you can run YPbPr at 15khz during VBLANK. It won't sync. On 480i signals, the video frames run at 63us OK, but jumps to 31us in VBLANK time.

 

I don't care about the colors at this point - I just want video from the Atari.

 

Bob

 

 

 

converting the RGB to YPbPr is quite simple in analog domain, i've already bought the parts for it, now i need to sqeeze some time to do it

basically its done by three summing amps with noninverting configuration

[Rybags]

That's a potential problem... the Ataris don't generate the half-scanline VSync pulses - they're full scanline - probably the main reason people have trouble with some LCD monitors and other devices. My HDD recorder doesn't like the Atari - the ST shows absolutely no picture and the 8-bit displays a rolling picture.

 

electron - I'll whip something up later today. Meantime, anyone can try that bit of Basic code in my previous post - it'll show bunches of horizontal lines on VBXE which aren't supposed to occur.

[Rybags]

vbxebug.bas

 

BASIC program to demonstrate the bug.

 

With initial PRIOR=0 value, you shouldn't get the changed colours but VBXE does. Also, other PRIOR values will cause fluctuations of the horizontal origin of the scanlines involved.

[electron]

vbxebug.bas

 

BASIC program to demonstrate the bug.

 

With initial PRIOR=0 value, you shouldn't get the changed colours but VBXE does. Also, other PRIOR values will cause fluctuations of the horizontal origin of the scanlines involved.

 

Thank you Rybags. I can confirm bug when PRIOR is switched from 0 to 0 - emulated GTIA behaviour is different in VBXE than in original GTIA. It is possible to correct this but I'm afraid of lack of FPGA resources in the case of FX core ... we will see...

 

But I haven't noticed any shimmering or shifting of the display ... What type of monitor do you use ?

[Rybags]

1084S - later type (white with switch on back).

 

The shimmering is kinda weird - I've had it come and go, only on the lines where the DLI is present (see pic before). It's as if the VBXE is doing the scanline a little earlier for a while then returning to normal.

 

Kind of annoying bug, but I suppose it can be worked around. In normal circumstances we don't change PRIOR twice in succession other than the odd demo or wanting to force the "special" multicolour mode.

[electron]

1084S - later type (white with switch on back).

 

The shimmering is kinda weird - I've had it come and go, only on the lines where the DLI is present (see pic before). It's as if the VBXE is doing the scanline a little earlier for a while then returning to normal.

 

Kind of annoying bug, but I suppose it can be worked around. In normal circumstances we don't change PRIOR twice in succession other than the odd demo or wanting to force the "special" multicolour mode.

 

I really dubt if this is VBXE responsible for this effect ... VBXE horizontal resolution is 640 px max and in my opinion this is not possible to achieve such a smooth shift of the edge of display - it really looks like a monitor has some problems with HSYNC .... Can you take a better photo of this distorted picture edge (better = sharper and with maximum possible zoom of left edge, including a few chars in this line where DLI is active) ?

[Rybags]

 

Closeup this time. I changed the border colour to near exact of the background just to prove it's not some trivial contrasting colours making the tube go weird type thing. As is, the monitor tends to hold a good steady image regardless of colour changes.

 

The weird thing is that it'll often not have the effect, but it'll come on after a while. Cycling PRIOR can see it come and go despite the rest of the display being unchanged.

 

Should also clarify - the effect also causes the scanline to be indented on the right hand side - so it's as if the scanline starts a bit early but the graphics still last the correct duration.

Edited January 4, 2010 by Rybags

[electron]

 

Closeup this time. I changed the border colour to near exact of the background just to prove it's not some trivial contrasting colours making the tube go weird type thing. As is, the monitor tends to hold a good steady image regardless of colour changes.

 

The weird thing is that it'll often not have the effect, but it'll come on after a while. Cycling PRIOR can see it come and go despite the rest of the display being unchanged.

 

Should also clarify - the effect also causes the scanline to be indented on the right hand side - so it's as if the scanline starts a bit early but the graphics still last the correct duration.

 

OK, "GRPIOR change from 0 to 0" bug fixed. Your example is working correctly, also "Invitro" by Seban/Slight works fine now. Thank you Rybags for your effort.

[Rybags]

So, what's involved so far as reprogramming our units out here in the field?

[electron]

So, what's involved so far as reprogramming our units out here in the field?

 

New core(s) will be published soon on Candle's www.spiflash.org page. Everything you need to reprogram your unit (flash new cores) is Atari program FC.COM available in vbxe package here:

 

http://spiflash.org/files/vbxe/release.zip

[flashjazzcat]

Just finished converting KMK's TEXTMODE.COM to ATASM - quite painstaking but it works. Why would I want to do this? The Last Word's source code is entirely in ATASM format. With working code which I just about understand, I hope to have a prototype VBXE word processor running by the weekend!

[flashjazzcat]

Question: I want to make an 80 column replica of LW's screen display using the XDL. How best to insert single blank scanlines at the appropriate places?

 

 

 

[Rybags]

Just have something like an initial entry of Repeat nn to get your top of screen blank lines.

Next entry, text mode + attributes if you want them too, Repeat nn scanlines (remember, multiply by 8 ), minus 1.

 

A single blank line entry would be just setting bit 1.2, 1.4 (disable overlay, disable attribute). Shouldn't need to bother with Repeat bit if it's only 1 scanline needed.

 

Then just keep doing entries for whatever you want the rest of the screen to do.

 

I've not really played with Text mode yet... I think you can also do shorter lines, e.g. only repeat 6 instead of 7.

Edited January 7, 2010 by Rybags

[flashjazzcat]

Just have something like an initial entry of Repeat nn to get your top of screen blank lines.

Next entry, text mode + attributes if you want them too, Repeat nn scanlines (remember, multiply by 8 ), minus 1.

 

A single blank line entry would be just setting bit 1.2, 1.4 (disable overlay, disable attribute). Shouldn't need to bother with Repeat bit if it's only 1 scanline needed.

 

Then just keep doing entries for whatever you want the rest of the screen to do.

 

I've not really played with Text mode yet... I think you can also do shorter lines, e.g. only repeat 6 instead of 7.

Thanks! I assume I keep dmactl turned off so that any underlying ANTIC screen data doesn't get displayed? Sorry if I seem a klutz, but I'm just starting to program this thing.

 

Presumably the "short" lines are how the condensed text modes are achieved in KMK's memo pad on the distro disk.

Edited January 7, 2010 by flashjazzcat

[Rybags]

DMACTL and Antic stuff... all up to you. If you don't need it, just turn it off.

 

When playing about though, it can be desirable to keep it active. Creative setting of priorities means you can have a bitmap or text overlay going, and still be able to do discernable editing and stuff via your normal E: device.

[flashjazzcat]

It's all becoming apparent: playing with existing code is the quickest way to learn.

 

 

Next it's on to the colour attributes and the palette (not keen on this particular palette). It's pretty intuitive, the XDL, when you get to know it.

 

Shouldn't DMA being turned off speed up the system some?

Edited January 7, 2010 by flashjazzcat

[Rybags]

Intuitive, yes... except one wrong bitsetting can totally screw the thing up and you're left to work out the mess.

I suppose a solution would be to use macros rather than building the things yourself.

 

Turning off DMA = same savings as per normal.

 

I did a bit of blit testing with VBXE bitmaps on and off - fastest of course is if nothing else is needing the RAM. Sharing VBXE RAM with Antic and/or having VBXE graphics slows down the blit.