Posts by pwsoft

The hex values B4/B5 will be seen as 85xx chip. The threshold is at a hex value of B8

If you want a brighter picture on a monitor I would expect you actually need to lower the "contrast" setting and increase the "brightness" setting on your monitor instead.

Quote from Jens

Wow - didn't know that the Chameleon menu supports tha A500 keyboard.

The menu only knows about C64 keyboard matrix and the two joysticks. Inside the FPGA design there are two separate scancode decoders that feed the c64 keyboard matrix overlay logic. One is for PS/2 keyboard stuff and one that decodes scancodes coming in from a A500 keyboard attached to a docking station. So it should not only work in the menu, but for everything running on the emulated C64 including games. Numeric pad emulates a joystick just like on the PS/2 keyboard. One of the numerical parenthesis toggles the port.

If that was all techno mumbojumbo to the read here it is in plain English:

The A500 works in the Chameleon core by very tiny magic gnomes in purple jumpsuits running around like crazy!

VIC-II: Unknown (B3 00 B21D PAL)

The B3 is inside the valid voltage range at 5 volt so no attempt is made to switch to 12v power (confirmed as second hex number is 00), but the B21D number is all wrong I guess because of the missing 12v.

Checked and I've one report in my database that looks similar to this case (which was resolved by lowering the switching threshold to B8 in a firmware update):

N. OK (weißer Screen) PAL 6569R3 25/84 "Unknown (BD 00 B21D PAL) "

Quote from Jens

So far, the calculation is two-step only (shift, add+shift). With a "two and a half" step approach, we may be able to introduce 37.5% and 62.5% brightness settings for scanlines.

According to the register layout documentation there are 16 programmable steps for the scanline intensity on the mk3 (linear in 6.25% step increments). If only 4 can be selected that is a limitation of the config tool.

There is a little bit of space left at the end of the image. Maybe could move a text string or two to create a bit of extra code space were it is needed. IF (big if) we look at that we should collect the other ideas posted in the past. I remember there was a wish to switch between mono and stereo through restore key which isn't possible currently. Might as well put that also in, when I dive into the code base anyway.

I don't think there is any specific reason it works like this. I guess mostly because it made the code small and easy to write. The code only takes action on a release and the timer that keeps track of "long press" is also reused as flag to see if the button was pressed at all. Using JZ opcode to check against zero (never pressed). Doing an action immediately when timer hits a certain value requires keeping track of the fact that it already happened and somehow stop the timer from overflow (or it will repeat actions while holding). As it is programmed now it relies on the fact the user will not press "forever" as I think it can overflow eventually and see it as a short press again.

So if you accept "code space restrictions" as a good reason, I have a valid explanation

No there is no direct sync control (anymore) in the beta9 releases. There is a fixed list of VGA resolutions, but not one that has the syncs completely "off".

If I remember that "lug 1200 to germany" event correctly. Jens did an CPLD upgrade on the accelerator that was already available, but not applied to that specific card (old stock). We didn't change anything on the 1200 itself. Initially the problem looked interesting, but once it was discovered the card didn't have the latest update, it became a standard fix. And I just took everything back the next Monday in working condition. That must have been years ago though.

We did address some of the mouse issues in later firmware versions. So that is very well possible that updating to the latest versions resolves the issue.

Optimal resolution for that monitor is specified as 1440x900 @ 60 Hz.

I guess best bet for the scale factor is to scale-up by exactly 1.75x. Resulting in a target of 1120x896 if you don't want to change the aspect-ratio of the Amiga picture. This will result in black bars left and right. Otherwise you could directly target 1440x900 (actually I would go for 1440x896 with 4 black lines as that has slightly nicer scale factors), but will stretch the Amiga picture horizontally of course.

Horizontal scaling would be 2.25x and vertical earlier mentioned 1.75x in that case.

1440x900 is a standard described here (not sure if it is a default in the config tool already):

http://tinyvga.com/vga-timing/1440x900@60Hz

Hi,

I've created a fix for the Graffiti emulation in NTSC modes. Copy the rbf file contained in the archive to your Amiga and flash with the configuration tool by using the firmware menu (right button to use menu) then select "Flash firmware file..." and select the rbf file.

Version of the firmware is 2021 11 04

agamk3_20211104.zip

Let us know if this solves the observed problem.

The only 15Khz with RGB input that I have, that could still be in working order (has been in storage for years so no idea) has scart input. So need to create a contraption to convert the 15 pin VGA connector into scart. Not high on my priority list at the moment. Once I'm back in action, I suspect I will be first put on a lot of Amiga stuff, as many items are still on the todo list from mid summer. I might be able to sneak a patch in when I work on C64 VIC-II stuff (a project like that is still in the planning some time in the future)

That said, even IF we add support in the main core, a lot of other cores will be unavailable to you when using a 15 khz monitor. Things like the VIC-20 and Atari 2600 cores don't have switchable video modes.

Because laptop cases are not standardized, and rarely sold separately without the motherboard/electronics/display already included. Also try to fit an 1541 disk-drive in a laptop and see how "portable" it will stay. And... Ideas are cheap (and we have plenty of those). It is the execution and implementation that matters. Also personally I would go for an Amiga based laptop instead. Either 3.5 inch floppy is doable or just boot from an CF card (technology that is already accepted on that platform as boot media)

Quote from robinsonb5

but then I remembered reading in the manual that the Chameleon can be used as a standalone drive emulator

Yeah, I knew it! Was relative easy to implement (we just had to make sure all IEC pins could be both input and output). I predicted, one day that feature would become useful for somebody. Took 10 years before I got the feedback, but there you go

I mean the TC has a IEC connector and a standalone power solution, would be kinda silly if it couldn't be used as a standalone drive.

Quote from ljmarent

Also, I had no idea that there was a Peter, or that he was on sick leave.

Hope he makes a strong recovery.

Well that would be me... I guess, unless Jens hides another Peter in his shop somewhere

I might be more known for my C64 stuff, maybe... If not, I programmed the firmware of the C64 reloaded MK2 (that menu thingy that appears on usb port serial so you can change settings) and of course many many things for the Turbo Chameleon 64. For Amiga I mostly did things "in the background", but had my contribution to many of the icomp "flickerfixers/scandoublers" or how you want to call those things, except the very first mk1 ones. The 1240/60 was the first time working on 680xx accelerators and now that got rudely interrupted.

I'll be back.

Hoi All,

I'm back... sorta... still recovering, but never mind that, I brought you a present.

An implementation of the gigatron TTL computer for the Chameleon. Including an emulation of pluggy the PS/2 adapter. The blinken-lights are mapped to the PS/2 numlock, capslock, scrolllock and the red LED on the chameleon (as there are only 3 LEDs on the keyboard). Green LED is same as numlock.

Remember: Flashy little shiny things = good.

PS/2 cursor keys map to joystick (you can also use the joystick port 1 on the dockingstation).
Delete/End is button A

Insert/Home is button B.

PageUp is start

PageDown is select (which changes the scanlines and as side effect cpu speed)

Right button on chameleon does a hardware reset.

Make sure you select the proper rbf for your platform chameleon1_gigatron.rbf for V1 hardware that is the one with the breakout cable and chameleon2_gigatron.rbf for V2 hardware that has the PS/2 connectors and data usb sticking out on the side. In chaco set "Flash additional Rom" the latest rom image is provided, but any should work (the actual hardware is fairly accurately emulated, it is TTL logic after all).

Pre-compiled binaries for both V1 and V2 and latest 128k gigatron firmware (select the proper one when flashing!!!)

chameleon_gigatron.zip

Full source code available in my fpga_examples github project.

https://github.com/pwsoft/fpga_examples

More information about the gigatron:

https://gigatron.io/

L8r,

Peter

For the IndiAGA mk3 we offer two options, either a 1 Kohm pullup or 100 pf capacitor on CCK. So yes suggestion is still valid for MK2cr that doesn't have this feature build in. If you notice small random horizontal lines appearing on the screen using high resolutions, adding the resistor might fix it.

It should be in the manual, copied following from Indivision_AGA_MK3_1200_manual_E.pdf:

By pressing left-shift, CTRL and Tilde (left of the 1-key) at the same time, you enter “live config mode”: Move the mouse to position the picture. Hold down the left mouse button and move the mouse to zoom in or out. Press Tilde one more time to leave live config mode. These settings are temporary, they are not saved in the flash of your flicker fixer.

One thing not mentioned in there:

If there are multiple settings that support the current resolution, the one first in the list is used, but pressing X allows you to cycle through all of them in live mode.

Yes the buttons can be tested with the hardware test. Little squares in the top left corner (should) light up when you press the buttons.