VBXE 2

[Rybags]

Candle:

 

I was just at a local computer fair 15 minutes ago. These guys had a stand there, selling the new Amiga, some robotics stuff, and a couple of AVR Programmers.

 

The prices seemed pretty good - $24 for the RS232 and $46 for the USB version. I didn't grab one as I have no idea if either will interface with VBXE.

 

Here's links to them on their shop's webpage - the brand name is "Inex":

 

http://pymblesoftware.com/store/index.php/ic-flashers-burners/px-400.html

http://pymblesoftware.com/store/index.php/ic-flashers-burners/px4000.html

 

ed2 - I found the Inex webpage. More info and downloadable manuals from:

http://www.inexglobal.com/products.php?type=micro&cat=AVR&model=px400

http://www.inexglobal.com/products.php?type=micro&cat=AVR&model=px4000

 

Of course, Question 2 is - just what will us VBXE owners need to reprogram our AVR for? Is it something that we all should have the ability to do? Isn't the GTIA/VBXE core part reprogrammable via the Atari itself?

Edited February 6, 2010 by Rybags

[jvas]

here are the screenshots of the supplied examples.

 

CMAP.COM produces the following image for me:

Does anybody have any idea?

[Rybags]

I was surprised when I saw that too on mine, but it is what's supposed to happen.

 

Colourmap allows selectively changing between hires/multicolour modes (bottom left) and also selectively replacing vertical stripes of PF2 within a cell with PF3 (pink lines through the green).

[jvas]

I was surprised when I saw that too on mine, but it is what's supposed to happen.

 

Colourmap allows selectively changing between hires/multicolour modes (bottom left) and also selectively replacing vertical stripes of PF2 within a cell with PF3 (pink lines through the green).

 

But in Heaven's post, the image looks differently. Or they were taken from an emulator?

[electron]

Rybags, the VBXE cores are reprogrammable by Atari (FC.COM utility in VBXE package). AVR firmware is responsible for automatic boot of the selected core and and other core-management functions available via FC.COM.

 

There is no new firmware for AVR on VBXE board available. Moreover, firmware updating is also available via FC.COM. So - you do not need AVR programmer solely for your VBXE device.

[candle]

As Electron already stated, VBXE contains everything that is reuqired both for upgrading cores and Atmel firmware if that would be nessesary

there is 6 pin ISP header for Atmel programming i was using during production, but it is there if s. hit the fan and one will get in real trouble

if it will come to that VBXE will need repair tech intervention anyways...

 

Jozsi: Heaven's pictures were screenshots from early stages of Atari++ with VBXE support, and revision it was emulating was something like 1.08. Your VBXE is running 1.20 core by default

[+rdemming]

what do you think, which is the best memory upgrade of a vbxe2 equipped 130xe?

I believe the VBXE2 does or can emulate a Compy 320K machine on its own, but I have one of Lotharek's 1MB upgrade boards fitted alongside VBXE and I'm completely happy.

 

The VBXE can indeed emulate a memory expansion using its own VBXE ram (Only if you have a 64K machine (800XL, 65XE, 800XE), not if you have already have 128KB like the 130XE). Good for "regular" programs that use extended memory.

But what if there is a VBXE program that uses extended memory? Then you can't use the VBXE ram as extended memory and then you need a regular memory expansion.

 

Robert

Edited February 7, 2010 by rdemming

[flashjazzcat]

The VBXE can indeed emulate a memory expansion using its own VBXE ram (Only if you have a 64K machine (800XL, 65XE, 800XE), not if you have already have 128KB like the 130XE). Good for "regular" programs that use extended memory.

But what if there is a VBXE program that uses extended memory? Then you can't use the VBXE ram as extended memory and then you need a regular memory expansion.

Well written VBXE apps should probably test for half the VRAM being devoted to a compy memory upgrade. If one isn't found, then it would be safe to use all 512K for graphics.

[Rybags]

Am I missing something here?

 

My impression is that the expansion emulation is just via MEMAC_B - so it's not really emulation in the sense that you can't select the extra RAM from PORTB.

[candle]

yes, you're missing something

ie fx v1.20R specs

[flashjazzcat]

Candle, is there a reliable way to test for half the VRAM being utilised as a 320K upgrade? Naturally we would use conventional algorithms to test for the presence of an upgrade on PORTB, but how to test where it actually "lives"?

[candle]

it is since core version 1.21

current is 1.22

where are these cores? well we have a little of delay here

i was hoping for some input from Gary or Thelen (some examples), but no such luck..

[flashjazzcat]

Any progress on what we discussed a while back regarding 80 column text?

[candle]

i hope so

[Rybags]

it is since core version 1.21

current is 1.22

where are these cores? well we have a little of delay here

i was hoping for some input from Gary or Thelen (some examples), but no such luck..

 

I've not touched my Core.

 

So... I take it we have some PORTB control to give us an emulated RAMBO 320 system in a later core version ?

 

Re test - wouldn't you use the "A" version core if you already have extended RAM. Doesn't the Config utility have the means to tell which of the 2 cores was booted - that should mean a user program can do the same.

 

I've not got expanded "normal" RAM - so I can't test any theories - but the dox did say early on that you can have contention where the expanded RAM will get precedence over MEMAC access. Maybe something along those lines could help differentiate between an expanded RAM + VBXE and VBXE only situation.

Edited February 7, 2010 by Rybags

[flashjazzcat]

I'm not too knowledgeable about the different cores, but if the cores which can emulate expanded RAM always emulate expanded RAM, then the procedure for testing is as simple as checking the core version number. I was under the impression there were extra and optional MMU/PIA connections necessary for the upgrade emulation (in order to intercept PORTB writes).

[+rdemming]

I was under the impression there were extra and optional MMU/PIA connections necessary for the upgrade emulation (in order to intercept PORTB writes).

 

Connecting wires to the PIA is not needed if a memory expansion "shadows" write actions to the PORT B register in its own extra hardware. The old Turbo-Freezer from 1986 was available with 256KB expanded memory and connected to the PBI bus of a 800XL. No need to solder anything, it just shadowed writes to PORT B in its own register.

 

Robert

[Rybags]

So, which core version do we need for PORTB RAMBO shadowing?

 

I've thought of a possibility for testing RAM expansion - since VBXE has a Soft-Reset by reading $D08x etc, maybe that method could be used to help detect if you have RAMBO or only VBXE expansion.

[candle]

why would resetting fx register set by writing to d08x would affect d301 shadow?

 

Gary, what do You think letter R in core name means?

beside this - You was given full specs of core detection scheme for cores 1.21 and above, so why to bother with any other detection at all?

[Rybags]

I'm still on Core 1.20 - where do I get the later version?

[candle]

it would be released with those examples You've provided

[+rdemming]

it would be released with those examples You've provided

 

LOL

 

@Rybags

If the core can't be detected in version lower than 1.21 there would be another way to detect if VBXE ram is used for RAMBO extended memory.

Assuming, the full 512KB VBXE ram is still usable with RAMBO emulation on, you can write a test value in VBXE RAM. Then read the equivalent memory location in extended RAM. If the read in the extended RAM is the test value, then the RAMBO ram is the same as the VBXE ram.

Of course, if you need to preserve the extended memory contents, you should store the value at the test location in extended ram before writing to the test location in VBXE ram. After the test you should restore the extended ram test location.

Repeat the test with a different test value, in case the test value you choose was accidentally the same a the value already in memory.

 

Robert

[candle]

i finally had some spare time to get converter i've wrote before connected to NTSC 1200XL machine

 

here is output it gave:

 

 

too bad it only works with NTSC machines

 

i have little hope of making it work on PAL one :/

[candle]

a little update

 

after separating HSYNC and VSYNC i was able to display this

 

 

as you can see, colours are way off, but i don't care about this right now - what i'm up to is stable picture, and currently its jumps a bit.

i think that extending v-sync pulse to something more than 50us (this is how long, or rather short it is now), but i've run out of 74ls123 chips

 

schematics for sync separator

 

if anyone has Gonbes GBS-8220 or can buy one to give it a try, please do so - i can't do everything by myself

 

here is example of hooking it up to the Atari ST:

 

so its definitly possible

[+bf2k+]

i finally had some spare time to get converter i've wrote before connected to NTSC 1200XL machine

 

here is output it gave:

 

...

 

too bad it only works with NTSC machines

 

i have little hope of making it work on PAL one :/

 

Is this the converter you were telling me about?