EclaireXL Issues Thread

toddtmw · August 7, 2019

The link to the keyboard overlays is on the keyboard page of the wiki on the website.

Start at 64kib.com go to the wiki, then the ExlaireXL project. Then wiki. Then either FAQ to keyboard page or scroll down and click link.

Link to FAQ:

http://www.64kib.com/redmine/projects/eclairexl/wiki/Faq

Todd

+Firedawg · August 7, 2019

Completed my keyboard with Atari key overlays. Helps tremendously when typing and looking for the necessary key stroke.

toddtmw · August 7, 2019

You might consider switching your ECXL settings to ANSI keybaord. That would effectively swap the :; key with the *^ key, which (i think) would make the arrows in a better place, but I also think then the arrows printed on the stickers would be backwards so maybe not...

NISMOPC · August 10, 2019

So, received my Eclaire today and got around to testing it out.

Ran into an audio issue. I am using DVI out to a monitor and the AUDIO out jack for sound. When I boot to basic and type or I am in any menu (Onboard, SDrive-MAX, AVGCart, etc.) the sound comes from L & R at same volume levels. When I actually load a game file from any device, the right volume is much louder then the left volume. I even used a pair of earbuds to test to make sure the built in monitor speakers were not bad. I get same results.

Has this issue been brought up in the past? @santosp @foft You guys have any thoughts on this?

EDIT: Done testing tonight, but tomorrow I will try HDMI out to a TV and see if I get same results.

Edited August 10, 2019 by NISMOPC
Update

foft · August 10, 2019

There are two pokeys. Main pokey goes to the left channel,

2nd pokey goes to the right channel. So unless software is using the 2nd pokey then it will be very biased to one channel.

The gtia is sent to both channels (it does the keyboard click.)

NISMOPC · August 10, 2019

2 hours ago, foft said:

There are two pokeys. Main pokey goes to the left channel,

2nd pokey goes to the right channel. So unless software is using the 2nd pokey then it will be very biased to one channel.

The gtia is sent to both channels (it does the keyboard click.)

Makes perfect sense. Thanks!

+DjayBee · August 10, 2019

Issues with my Eclaire mini (core 28):

Epyx releases of Rescue on Fractalus and Ballblazer fail with "LOAD ERROR"
This seems to be a problem with the disk emulation because both run fine when loaded from an SIO2SD.
The symptom is identical to a failed copy protection but does also appear with my cracked version - which still uses the specific implementation of the SIO code in their loaders.
Audio does not work over HDMI when connected to a Yamaha RX-V771 AV receiver. There are only some weird noises coming through.
This is not a general issue because with my TV it works fine and as workaround I use an additional analog audio cable.

Unfortunately I have no means of upgrading the core to the latest one at the moment to verify if the issues are solved meanwhile.

Rescue on Fractalus! v4.1 (1985)(Epyx)(US)[!].atx Rescue on Fractalus! v4.1 (1985)(Epyx)(US)[!][cr CSS].atr Ballblazer (1985)(Epyx)(US).atx Ballblazer (1985)(Epyx)(US)[cr CSS].atr

Edited August 10, 2019 by DjayBee

foft · August 10, 2019

Re Epyx: Thanks for the report. Would you be able to figure out what is going on in more detail please? I know some atx timing tests still fail on the test suite. I guess with an sio2pc attached can capture the packets?

Farb ran into that audio issue. I’m not really sure how to debug this one, seems a few devices do not like the output. If you switch to pure dvi then it will at least silence the screen. The newer core does not fix the issue, though I’ll check if the upstream design has a fix.

foft · August 10, 2019

The core be upgraded with just an sd card, using the menu. Put the latest .rpd file on there then select the flash rpd option. Make sure it’s the right one, if it doesn’t work you’ll need a usb blaster to fix.

NISMOPC · August 10, 2019

Got some more testing in. Been very pleased so far. Video quality is outstanding. Have my P:R:Connection ICD, Wimodem232, SDrive-Max and 2 1050 drives all hooked up and working with no SIO interruptions or interference.

Current issue:

I am able to load P:R:Connection ICD floppy version of 850 Express with my 1050, but it will not load completely using SDrive-Max and an ATX image. I have tried several things inclusing setting to 128K XE/XL compatible and even tried the 1050 option within the SDrive-Max config menu. It acts as if it is loading, shows the 850 Express title screen then instead of going into the program, it goes directly to blue screen READY prompt.

This ATX works fine with my 800XL and 130XE. Is there an option I need to set or select to have better ATX compatibility or other ideas?

+DjayBee · August 11, 2019

On 8/10/2019 at 2:08 PM, foft said:

Re Epyx: Thanks for the report. Would you be able to figure out what is going on in more detail please? I know some atx timing tests still fail on the test suite. I guess with an sio2pc attached can capture the packets?

Farb ran into that audio issue. I’m not really sure how to debug this one, seems a few devices do not like the output. If you switch to pure dvi then it will at least silence the screen. The newer core does not fix the issue, though I’ll check if the upstream design has a fix.

Debugging this is quite difficult because the loader implements its own SIO routines instead of using the OS's. To check for protection it reads the drive's staus byte directly from SERIN and "reacts" to it. If the code is "bad CRC" then it silently discards the read data and reads a diferent sector.

There is no timing involved in the copy protection, only sectors with bad CRC.

I will try to jump into the Freezer and analyse memory locations when it fails and report back. This way we might find out at what stage the load fails.

Is there a way to set a breakpoint which jumps into the freezer?

Regarding the audio issue:

I have worked around it by changing the logical input of the AVR to use an analog input instead of the HDMI's audio stream.

On 8/10/2019 at 2:11 PM, foft said:

The core be upgraded with just an sd card, using the menu. Put the latest .rpd file on there then select the flash rpd option. Make sure it’s the right one, if it doesn’t work you’ll need a usb blaster to fix.

For the Eclaire Mini this would be "build_A4EBAv3rom".

Correct?

You might add some readme about the versions in http://www.64kib.com/autobuild

foft · August 11, 2019

The mini was made with smaller and larger fpga versions, check which one you have by the text on it. Will be EBA2 or EBA4. The v3 ones are the ones you need for the mini.

http://www.64kib.com/redmine/projects/eclairexl/wiki/Core_location

As for freezer breakpoints, not sure I will have to read the manual.

With the logic analyser I can capture a trace but typically only a few instructions, eg trigger on write to address x and capture some traces.

Edited August 11, 2019 by foft

foft · August 20, 2019

Well I confirmed that these ATXs still fail on the latest core. To set breakpoint I think the only way is to modify the code using the freezer to do something!

Perhaps you can see something I did wrong in handling the drive status byte in these?

http://www.64kib.com/atarixlfpga_svn/trunk/atari_800xl/firmware_eclairexl/atx.c

http://www.64kib.com/atarixlfpga_svn/trunk/atari_800xl/firmware_eclairexl/atari_drive_emulator.c

It would be cool to be able to remote debug the system using the jtag and wudsn. One day!!

+DjayBee · August 20, 2019

1 hour ago, foft said:

To set breakpoint I think the only way is to modify the code using the freezer to do something!

Would it be possible for the core to automatically push the Freezer key F12 when the emulation's PC hits a certain address or it reads/writes from/to a certain emulated address?

foft · August 21, 2019

15 hours ago, DjayBee said:

Would it be possible for the core to automatically push the Freezer key F12 when the emulation's PC hits a certain address or it reads/writes from/to a certain emulated address?

Yes certainly, good idea. Address comparator + or gate. I’ll add that feature to the new debugging sub-menu:)

+DjayBee · August 21, 2019

One more feature request:

One of my HDMI displays has no possibility to set the aspect ratio to 4:3. Therefore it would be nice if the Éclaire's video output could be switched to having black bars on the sides.

foft · August 21, 2019

7 hours ago, foft said:

Yes certainly, good idea. Address comparator + or gate. I’ll add that feature to the new debugging sub-menu:)

I decided to add address check, read or write check (optional), data check (optional). Also I need to trigger an NMI to trigger the freezer. Of course the status will change somewhat due to the NMI then NOP slide. Still useful or do I need to investigate somehow getting the freezer directly to activated mode?

foft · August 21, 2019

3 minutes ago, DjayBee said:

One more feature request:

One of my HDMI displays has no possibility to set the aspect ratio to 4:3. Therefore it would be nice if the Éclaire's video output could be switched to having black bars on the sides.

Not really ideal, would have to have non-integral scaling since its still 720 pixels. Of course there are options, for example the open source scaler from the mister project. Does your monitor switch automatically to 4:3 mode from other sources? Perhaps there is a packet or flag I can send.

+DjayBee · August 21, 2019

Oh, I see. That's not worth the effort.

My amateurish idea was that the actual horizontal output would be 4 pixels per single Atari pixel. Then it would have only been a reduction to 3 pixels per Atari pixel sourrounded by "some black".

+DjayBee · August 26, 2019

On 8/20/2019 at 9:31 PM, foft said:

Well I confirmed that these ATXs still fail on the latest core. To set breakpoint I think the only way is to modify the code using the freezer to do something!

Perhaps you can see something I did wrong in handling the drive status byte in these?

Unfortunately I cannot debug it on the Éclaire. After the load error screen shows up, it does no longer react to pushing the Freezer key.

Jumping into the Freezer's debugger from the Atari seems not to be possible.

On 8/21/2019 at 9:33 PM, foft said:

I decided to add address check, read or write check (optional), data check (optional). Also I need to trigger an NMI to trigger the freezer. Of course the status will change somewhat due to the NMI then NOP slide. Still useful or do I need to investigate somehow getting the freezer directly to activated mode?

You might contact the author to ask what you could do inside the hardware emulation to jump directly into it:

hias+atari@horus.com

+DjayBee · August 26, 2019

On 8/10/2019 at 2:11 PM, foft said:

The core be upgraded with just an sd card, using the menu. Put the latest .rpd file on there then select the flash rpd option. Make sure it’s the right one, if it doesn’t work you’ll need a usb blaster to fix.

It constantly fails for me.

I copied the 20190719.rpd to: root-of-card, atari800, atari800\rom and atari800/user.

When I select "Program RBD" from the settings menu then NOTHING happens.

You wrote "select the flash RPD. The menu shows "Program RBD".

Probably stupid question : What am I doing wrong?

Roydea6 · August 26, 2019

2 hours ago, DjayBee said:

I copied the 20190719.rpd to: root-of-card, atari800, atari800\rom and atari800/user.

Should be atari800/user/myfolder >20190719.rpd

myfolder=any folder of your choice to remember to go to before selection of program RPD

foft · August 26, 2019

Program rpd brings up a file selector (press fire or enter), so you can navigate the filesystem.

+DjayBee · August 26, 2019

43 minutes ago, foft said:

Program rpd brings up a file selector (press fire or enter), so you can navigate the filesystem.

I always "selected" the menu entry with enter. You actually have to push "arrow right".

Now it worked.

foft · August 26, 2019

Oh weird, that must be a bug. I checked the code before posting and found this:

#ifdef RPD_SUPPORT
		{0,"Program RBD",&menuProgramRBD,MENU_FLAG_FIRE|MENU_FLAG_SD}, 
#endif

i.e. the code say fire not right.

I also found this which looks worrying!! I mean no check on the return from file_selector... I'd better look at that to check if nothing is selected it doesn't try to flash garbage.

#ifdef RPD_SUPPORT
void menuProgramRBD(void * menuData, struct joystick_status * joy)
{
	fil_type = fil_type_rpd;
	filter = filter_specified;
	file_selector(files[4]);
	flash_rpd(files[4]);
}
#endif

Edited August 26, 2019 by foft

EclaireXL Issues Thread

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members