Re: Amiga core status

I think the problem I encountered was with my power supply, it was 5V 1A, I'm guessing it can't deliver enough power to run the replay with two mice when it's cold. Today I went to boot up the replay with the Amiga mouse plugged in and it would not boot, I noticed the green led next to the joystick ports going on and off. I boots up fine when only the PS/2 mouse is plugged in, when the Amiga mouse is plugged it won't boot until the power pack has warmed up. I swapped it over for a 2.5A power pack and it works flawlessly with both mice plugged in

827

Re: Amiga core status

Oh, got the same power supply as you 5V 1A, could that explain the non working ps2 mouse? What's the power requirement for the board?

828

Re: Amiga core status

". Turn on the board, mouse light comes on but no pointer
. Booting core
. Mouse still not working but light still on
. Unplug/replug, mouse is now working"

That's strange - sounds like the mouse lights up when it has power, but is not initialized. Email me the exact type and I'll try and find one the same to play with.

I would be surprised if 1A was not enough, but if you are getting a voltage drop the board will flake out - especially with long cables to the board. It's best to power it from the Molex if possible (only 5V is required).
/Mike

829

Re: Amiga core status

gouky wrote:

Oh, got the same power supply as you 5V 1A, could that explain the non working ps2 mouse? What's the power requirement for the board?

Highly dependant on core. It was <500mA before, but we are probably pulling more now with the Amiga core. I think the drop on the 5V is more of an issue. Note, it doesn't affect the FPGA as all the other supplies are regulated from the 5V, but old mice especially seem fussy about the 5V rail.

830

Re: Amiga core status

@mike, are you using a true ps2 mouse or one with an usb adapter as well? Do you have a ref? I think I'm gonna get one on ebay or amazon. I'll check the different ref tonight and let you know.

831

Re: Amiga core status

USB with adapter. Intellimouse ps/2 P/N X800472-105
I'll have a play with some other ones.
May be a problem with the init I guess - or more like they give up talking ps/2 by the time the fpga is booted.
/Mike

832 (edited by gouky 2015-08-21 18:09:57)

Re: Amiga core status

Thanks, I will try get one, in the meantime having the amiga mouse support is really handy! :-)

Re: Amiga core status

I am using a true PS/2 mouse from a HP machine.  I also tried a USB adapter at CommVEx last year... be aware, there are many USB->PS/2 adapters that do not work.  Something about supporting some later protocols.

834

Re: Amiga core status

well I'm out of luck only 1 mouse on 5 is working correctly, I've tried with 2 different usb to ps2 as well sad

835

Re: Amiga core status

I'll go collecting mice then....

836 (edited by gpz 2015-08-23 10:31:06)

Re: Amiga core status

be aware, there are many USB->PS/2 adapters that do not work.  Something about supporting some later protocols.

not exactly. most "USB to PS/2" adapters out there don't actually translate USB to PS/2 at all - its pure rewiring of one plug to another. the keyboard or mouse that is used with them must speak PS/2 (which most of those do anyway, but recently USB only devices are creeping into the market too, and those will not work).

837

Re: Amiga core status

Correct. Let's move this to a mouse thread ...

838

Re: Amiga core status

Back to the Amiga and tidying up the top level so it builds with the library changes...
I can now continue with the RTG after this "replumbing".

The DRAM controller is working fine in simulation with the second channel by the way, so I expect to see some lovely pictures soon.
/MikeJ

Re: Amiga core status

Hi Mike smile

New firmware available with speed improvements on SVN please ?

Thanks, Laurent and Franck
Amedia Computer

Amedia Computer France
Site : [url]http://amiga.amedia-computer.com[/url]
Mail : laurent@amedia-computer.com
Skype : faranheit57

840

Re: Amiga core status

Not yet, I wanted to finish the ground work on the RTG. I'll stop faffing with Pacman and get back on the cache ...

Re: Amiga core status

Hi Mike wink

Great news for RTG integration, this should ease the use of high resolution modes for Workbench 3.1 / 3.9 wink

Thanks, Laurent and Franck
Amedia Computer

Amedia Computer France
Site : [url]http://amiga.amedia-computer.com[/url]
Mail : laurent@amedia-computer.com
Skype : faranheit57

842

Re: Amiga core status

Right, I've reproduced some issues with the blitter. I'm not sure exactly what is going wrong yet, but I'm simulating an entire frame including quite a complex copper list (from Menace), so I'm pretty sure I'll nail it...

843

Re: Amiga core status

If anybody wants to see what's going on, you can use this .ini file and the binaries. The system will upload the code to the correct place and jump directly into the code - no OS involved. Makes debugging a lot easier!

Post's attachments

sdcard_menace.zip 310.4 kb, 9 downloads since 2015-09-06 

You don't have the permssions to download the attachments of this post.

844

Re: Amiga core status

Right, good news.
I've now simplified the test case, removed the scrolling and just blitting the same tile in a grid. They are all messed up in different ways. This means it's really broken, and should be easy to fix....

845

Re: Amiga core status

Simplified it now to a single plane blit going wrong.
I don't need to load in any Manace files now, which really speeds up the simulation startup.
The Amiga testbench can load .srec /binary files as well, so I just copy across the code which goes wrong on the hardware and we should see something in the sim.

It takes about 10 mins to simulate a whole frame on my machine.

I attach the files for your amusement. (The blit_test.asm is just hacked around to get something which shows the problem as simply as possible)

/MikeJ

Post's attachments

blit_test.asm 25.1 kb, 2 downloads since 2015-09-06 

blit_test.bin 2.66 kb, 1 downloads since 2015-09-06 

bootstrap.bin 62 b, 1 downloads since 2015-09-06 

replay.ini 8.61 kb, 2 downloads since 2015-09-06 

You don't have the permssions to download the attachments of this post.

846

Re: Amiga core status

Right, found one problem.
The Menace code does not wait for the blit to finish, and starts another blit quickly afterwards. It relies on blitter nasty being set to stall the CPU.
On Replay in fastest mode, the CPU is still getting in every second system (7.xx MHz) clock cycle.

On a real A500, if you blit with just A and D terms, will it completely block out the CPU?

From what I understand, a DMA or CPU cycle is two 7.xx MHz cycles (one ~3MHz colour clock?) In which case, I think it can saturate the bus on a real machine.

A DMA cycle only takes one 7.xx MHz cycle on replay, so three slots are available for the CPU.

One workaround (call it blitter compatible or something) is when nasty mode is enabled to lock out the CPU for the cycle after every blitter operation as well.
Thoughts?
/Mike

847 (edited by JimDrew 2015-09-07 00:38:17)

Re: Amiga core status

It was very common for programs to not wait on the blitter to finish, and relied on the fact that the stock CPU was held off so code would not access the blitter before it was done. When accelerators came out that caused quite a problem in situations like this.  However, Menace works fine with an accelerator, so it must be something to do with the terms.

Re: Amiga core status

The Whdload guys have a BlitWait function because of this. They also have a special slave for speed benchmarks which might be helpful:
http://eab.abime.net/showthread.php?t=31758

849

Re: Amiga core status

If the code is running from chip it will still stall, even with the accelerator. This is probably what happens with Menace. If you don't stall the CPU, the next blit goes wrong. (my comments with **)

blitfgnd

** 1st bitplane
        move.l  d1,bltdpt(a6)           blit a 16x16 pixel block
        move.l  d4,bltapt(a6)           into the foreground screen
        move.w  #$0401,bltsize(a6)      unmasked with no shift
       
** 2st bitplane         This blit is started without waiting for the previous one to finish. Relies on blitter nasty being set
        add.l   #32,d4
        move.l  d2,bltdpt(a6)
        move.l  d4,bltapt(a6)
        move.w  #$0401,bltsize(a6)
       
etc

I have a potential fix for A500/A1200 timing mode.
Currently I have a 1 in 4 enable for the a500, and if a CPU cycle is delayed I hold off a cycle. What I need to do is only let the CPU move a complete original memory cycle (2x ~7MHz clocks) not one. If I do this, the CPU will stall correctly when the blitter is busy.
When the CPU is in "fast" mode, it will get in 3 out of 4 cycles even if the DMA is fully used.

850

Re: Amiga core status

Thinking about it some more, we only care about the following modes. I'm not very keep on lots of "tweak" options, they can be confusing.

1 - A500 memory bridge (Agnus)+ 7MHz CPU
  Here the CPU is enabled one in four 7MHz cycles, can move to one of two 3MHz phases. One DMA cycle in four 7MHz cycles. This would give correct DMA contention, correct chip mem speed. Fast mem accesses take the same time (the CPU is the slow bit here) but do not have contention with DMA.

2 - A1200 memory bridge (Alice) + 14MHz CPU
  CPU gets 2 out of four 7MHz cycles, DMA one. Chip access speed should also be correct.

For both (1) and (2) we could have a "enhanced DMA" option, where the disk and blitter can use spare DMA cycles.
The CPU would wait for slow devices (CIA).

3 - "Fastest CPU possible + enhanced memory bridge. With/without cache option.

The enhanced DMA option would now allocate more resources to the DMA, 50% rather than 25%.

The only other interesting case I can think of, is A500 hardware with an accelerated CPU and it's own fast mem. But this is sort of what we get with (3) anyhow.

I would remove the "accurate timing" option as all it is doing is slowing down chip memory access - and not correctly.
Comments?