interface idea's

[simbo]

what would be good and a nice project maybe popsel or ppera can make up
im busy doing a dll for a company still
is a small board with two pic 18F452 or similar
to act as an data director signals generator
and both can access the buffer memory when its not busy
if its busy sends drive not ready etc....

it can have a smart card on it that acts like a floppy type store
and can be formated via the atari or pc a serial connection /acc can be used to switch the floppy store/mode etc
some lcd for menus could easily be read into the lcd from the card....

then the unit should have two floppy connectors on it
one for pc one for atari {both drive a's}

then there is a simple drag and drop share solution
without any hdd probs
at a resonable speed nice easy and simple!!!
and with a tweak to the floppy controller twice as fast ...
what do you think ???
mug posted a similar solution although it relys i think on changing the card and has a menu superimposed to the screen
the two floppy solution would only create an o/s platform issue with winxp and above
adding a second o/s like win98/me is one way
using a second small hdd on the pc or a partition and partition magic
so files can be edit and seen on both this i think can be fixed as its just one byte missing
or byte allignment if i remember

views please???

??

[ppera]

Hmmm.... I think that after some 15 minutes I start to understand the idea. Using some buffer memory to act like floppy for both Atari and PC... With interfaces of course.

I find it as too complicated, and nothing better than existing serial, parallel, net connections.
+ we have some finished floppy emulator project(s) on market.

[simbo]

hum thinking about it your obviously correct
so...... as a launch pad to a new joint project within atari forum

maybe has its own sections with other like pperas and popsels alisons stuff {projects in hand completed ideas etc ,,, this way it avoids colussion and arguments etc dont know
ill ask... the dukes!!
.....
then the best way for transfers is in a joint project
that connects the cart port and a second dma {i mean not for transfers as such like dma but can use an atari driver to do this also}
direct to usb/1/2 {multi o/s platform etc }
and also steem and other sims via a cart port interface as a mirror system

ive seen a project that does this or had the potential
but it seems abandoned and not using the right steps and has a smart card and some other interfaces on it like the net etc...
it uses too many i/o pins on the micro and avr/52/pic etc micros

instead of fast serial via atariclk(on-int)=parrallel>serial chips for address etc and atariclk(sync) =serial > parrallel for data

both interface chips that do in electronic terms isolate the valuable micro
from the atari and it also can this way be made plug and play.....!!!!!!{run a game plug it in and monitor hehe!!}

youll need 3 chips hct cmos and some sort of cashe 1 X16 bit micro controller and usb
but its far better for more than just ide and loading roms and running hungry dongles people use

the old cart port is afterall the best overall port
capture mode is also possible by just a monitor capture etc program on pc
a widely avalible port is prob the best via usb that can also pass commands to the micro on the card
i will write the usb drivers http://www.ftdichip.com/ and the api for any c apps to command the interface
this is far within my grasp of c++ and windows as for other o/s i can do it via one of the freeware licences and make it cross platform easily

just over the river from me..... ftdi a bike ride away ...!

......

if you fetch 16 bit data to serial its far better than clocking it into an i/o bus on a micro c
as the micro is tied up doing this
receiving a whole serial byte packet is much faster and closer to real speed
giving a micro much less tasking time on recieving an address and more on processing data
serialising it also aids in the convertion to usb interlace etc standards
its just stupid to ignore it
rom signals maybe arent needed as interception is easier using it {block packets etc....!}
change is a matter to intercept the change and change it .... before its stored to ram as interception itteration of dram data
using flash roms is easier in both directions
taking over the whole atari is also easier
virtual hardware atari via cart port and maybe rs232 direct connect to the k/b 5pins {-kb hardware} is also possible

an extra connection or two would be needed

like pin 2 u104 {ste} reset line
or some system to allow a soft reset

hard reset can also be made using a small psu to board to atari plugin
switcher also driven by an i/o

it would be a great addition to the eiffel systems
as a second driver {easy......}

this way with a few extra signals a pc can hold an atari to command
in soft reset hard reset or cleared signaling

[simbo]

if we have an interface like this
then maybe it can also have a ram cashe to allow inserted media cards to be cashied
then when removed signals are re-routed via drivers /acc etc tsr too allow plug and play
and stacked
more to the stacking idea i posted a year or two ago
but better fitting to very little alterations of the ataris case etc struct
whilst gaining max accessabilities


some auto progs can be used 'when instered a smart cashes to eram if avalible' etc...

this would yield a small load time and instant access to all programs avalible on eram

[alexh]

Can I suggest that if anyone tries to create a stand alone floppy disk emulator (i.e. some sort of flash, SD, CF etc. to internal floppy connector) that they try to use a default boot disk rather than use an LCD screen?

Using an LCD on the floppy disk emulator (to select the disk image you want) adds serious cost to the device. Why use one when you have an Atari ST connected to a TV and mouse/keyboard?!

The floppy disk emulator on power up would serve a default disk image from the SD card. It would be small, just a few sectors. This image would contain a boot program (which would need to be different for whatever host you are running on). The floppy disk emulator would serve the directory contents of the SD using the remaining sectors of this virtual disk. (I am not denying that it require some clever code to convert the current SD card contents dynamically into virtual disk sector data)

The boot program then uses the hosts gfx and I/O (in our case Atari ST) to display a selection menu on the Monitor/TV screen. Disk image selection would be made using the keyboard and mouse. The selection would be passed to the floppy disk emulator using floppy disk write commands that it can interpret.

After the image(s) are selected the user (or the boot menu) could then reset the host computer and the selected disk would load as normal.

Once a disk image has been selected it would continue to be served until power off or a button is pressed whereby the floppy disk emulator would default back to serving this boot disk image. (Or perhaps select the next stacked disk image)

It would be advantageous to make the PCB the same size as a standard floppy disk drive so that it would fit internally and make the control interface only one button (the eject) and perhaps use it in a similar way to the Mac mouse (single click = forward through disk image stack, double click = backwards, click and hold = return to default image etc).

I am sure you could find suitable programmers to produce the boot menu program for each platform. If the API was open-source then communities would almost certainly write their own!

[Jookie]

alexh, now that's a good idea of how it should work! I like that. And if I would be not too busy after my current project, I would probably do this as my next project

Jookie

[simonsunnyboy]

I agree - that's definitly a better solution than having to solder wires to the video circuita just to have an overlay disk image selector.

However such a solution should be able to support disk switching WITHOUT reboot of the ST. If one has to reboot for every disk image change, its usefullness is quickly lowered to nearly useless as you gain no advantage over swapping real floppies.

[Jookie]

However sucha solution should be able to support disk siwthcing WITHOUT reboot of the ST.

Well, why should you reboot for the disk switching? Alexh wrote: 'single click = forward through disk image stack, double click = backwards, click and hold = return to default image etc' - so I imagine you would need to use the menu manager after reboot i.e. for:
- selecting a group of images from all images through which the user would cycle when he presses the button
- selecting the 1st image to which it would switch if you would 'click and hold' the button
...and so on. So the reboot would not be needed.

Jookie

[simonsunnyboy]

That's a severe limitation! You often do not know in advance which disk images are going to be used.
In the end one would be left with having all images in the list and cycling through all of them until the right one is there...

[Jookie]

That's a severe limitation! You often do not know in advance which disk images are going to be used.
In the end one would be left with having all images in the list and cycling through all of them until the right one is there...

I imagine it like this: you want to play a game which uses 3 diskettes, so you restart the ST, in the utility you select only those 3 images which the game uses (you have 500 images on the SD card, but you select only images 'Game XXXXXX 1/3', 'Game XXXXXX 2/3' and 'Game XXXXXX 3/3') and then after restart when you press the 'Cycle image' button on the device, you cycle only through those 3 images which are used by that game you want to play. If you want to play another game, you select another group of disk images for that another game. This way you wouldn't need to cycle through all 500 images.

Would that restart between playing two different games be that much of limitation?

In the example I wrote above I know exactly which disk images are going to be used. Could you please describe a situation, which would require a better way of image selection?

Jookie

[Mug UK]

How it works on SDiskEmul is via the extra joystick port that's part of the device. I'm still waiting for my mate to pop around and get it installed as it's way beyond my knowledge spectrum (which is fairly limited anyway hardware-wise) but:

Select the disk image for virtual A: drive, and boot from it. If it asks for disk 2, 3, 4 etc., press the fire button on the extra non-ST connected joystick and use the overlay screen display to select another image for the required disk. Wait a second or two and press the space bar/joystick button on the game and it should now detect that disk 2 is in the 'drive'.

[Jookie]

How it works on SDiskEmul is via the extra joystick port that's part of the device.

I've took a look at the SDiskEmul, and if the schematics and FW/SW are free, then there is no need to develop almost the same device (only if the new device would not use the menu with images displayed as overlay on the TV)...

[simonsunnyboy]

It is a limitation when you want to do more than gaming, e.q. development or using different data disks for music software/art packages/etc.etc/etc.

I agree the scheme you propose is entirely sufficient for ROm kiddiez style use

[Jookie]

It is a limitation when you want to do more than gaming, e.q. development or using different data disks for music software/art packages/etc.etc/etc.

I agree the scheme you propose is entirely sufficient for ROm kiddiez style use

Hmm, I haven't thought about that one... Well, then for the better image selection there are at least 3 choices:
- the overlay menu on TV like SDiskEmul
- small 2 (or 4) line LCD display on the device
- serial terminal on other computer (i.e. PC)

Jookie

[alexh]

such a solution should be able to support disk switching WITHOUT reboot of the ST.

That should be easily possible. Rebooting is not an essential part of the system. I only wrote about reboot after disk selection as 9/10 users will want to do that. Quit from the disk selection menu without reboot will be equally valid.

It is a limitation when you want to do more than gaming, e.q. development or using different data disks for music software/art packages/etc.etc/etc.

If you take into consideration what I say above. You can press and hold the eject button. That makes the floppy disk emulator switch to serving the the default disk image. On an Atari ST you would (in TOS desktop) browse to A: and then the AUTO folder. Double click on the boot menu program icon. The menu program loads. You select a new (set of) disk image(s). Select the option to quit without reset. Voila.

[Mug UK]

SDiskEmul is not really aimed at developers - the same piece of kit will work on Amiga, Amstrad *and* our beloved Atari ST's.

As SSB pointed out, it's more for the Rom Kiddiez than anything else. I wanted it purely to store the 1000's of PD disks I have on the one (or two) SD cards and save some space

[alexh]

SDiskEmul uses a Monochromatic composite video output to select images?

What I am suggesting are just "improvements" that could be made to such a system as far as disk selection and physical PCB form factor go.

It should be easy to make the changes I suggest. The PCB could easily be shrunk to the size of a floppy disk drive. The single button could easily be made to connect to the eject button (although coming up with a mechanical design that works with all computers will be more challenging).

I understand that using the MCU on the emulator to create a 2nd video output is quicker than writing the default boot menus for each system. But ease of use is definitely lowered.

[simonsunnyboy]

How is this eject supposed to work? The ST would have to load some soft from this "Default image" which will trigger the disk exchange. This is likely to override what is currently in the memory. You'll probably need to supply a big TOS patch too...

[alexh]

How is this eject supposed to work?

You press and hold the eject button. The device switches to the default boot image. (Which does not necessarily have to be autobooting)

The ST would have to load some soft from this "Default image" which will trigger the disk exchange.

Correct. I had the idea that with this host software you could select more than one image (for multi-disk games). You could then trigger future disk exchanges (within this subset) without using host software with a short press of the eject button.

This is likely to override what is currently in the memory.

No more than loading any other OS legal TOS application.

You'll probably need to supply a big TOS patch too...

Why? I do not think so... but I am not a TOS programmer.

[simonsunnyboy]

This is likely to override what is currently in the memory.

No more than loading any other OS legal TOS application.

Arf! That is exactly the showstopper to my initial problem: wanting to use stuff without reset/reboot/reloading of application.
As now I cannot load appliction A from disk 1 and switch over to data disks a,b,c,d and x and, surprise surprise I want t o sue data disk t too (which I ddin't plan at first). SO now I have to stopp application A, load the image switcher and load A back?

Thanks - then one can go back to real floppies!

[alexh]

I understand where you are coming from. You want to swap in an arbitrary disk image you didn't think of when you launched your application without having to quit.

I realise this is an excuse, and I realise that not every system would have one, but in the case of an Atari ST if you were doing anything like this, would you not use a hard drive?

I think this is a slightly contrived situation. But it is something to think about. But do you not agree that "stop application A, load the image switcher and load A back" is no more work than:

• Pick up the TV remote.
• Change to AV2.
• Pick up the floppy disk emulator joystick.
• Select the file.
• Put down the joystick
• Pick up the TV remote
• Change back to AV1.

No?

[simonsunnyboy]

AV2 means the device has its own video circuitiry. If it is independant from the ST (beside the floppy cable), there is no need to reboot the ST.

And actually developemnt on the ST is possible with using floppies only - did so for 17 years until SatanDisk (which is no substitute for floppies when you have stuff which is not running from it, e.q. coyp protected software)

IMHO we disagree fundamentaly in the view of the ST and its uses - so I probably will end with not considering such a replacement.
for me it is no game conole where you just stick ROMz in and out....

[alexh]

AV2 means the device has its own video circuitry.

Yes. The SDiskEmul discussed earlier can combine it's own output with that of the host on the same channel but this has been known to lower the video output quality. I am suggesting a system that would not need to have such circuitry or an expensive LCD display that other systems use.

If it is independent from the ST (beside the floppy cable), there is no need to reboot the ST.

But then you need a mechanism by which you can select and change disks. Either the aforementioned video circuitry (which is just a wire and good software) or an LCD and some sort of input mechanism. Separate buttons or joystick interface.

IMHO we disagree fundamental in the view of the ST and its uses

I do not think so. This was an early idea. People discuss ideas and contribute to them. They objectively look into the pro's and con's. That is how good ideas grow into great ideas.

- so I probably will end with not considering such a replacement.

Would you seriously be considering SDiskEmul or one of the other floppy disk emulators?

I am not creating anything. I am just suggesting some of my ideas I've had for a while about this subject to those who might be.

for me it is no game console where you just stick ROMz in and out....

I believe that you are in the minority. I (like most creative users?) use an emulator such as STeeM to develop and then use the real ST to experience the development. To use a real ST would be masochism! (Apart from the odd nostalgia trip)

[simonsunnyboy]

I actually would try Sdiskemul if i could find a site selling it with readable language (aka no French) and fitting it. LCD + buttons is fully ok from my point of view....

And yes, I am part of a minority - and I'm proud of this Why stick with a boring mainstream when you can distinguish yourself from the others?

Do what you please, this is a free world but I hope I made some points clear....it is discussion and not a fundamental no go. Just me disagreeing doesn't necessarily mean it is entirely unrealistic....

[alexh]

I think the software generated Luma output of SDiskEmul is a great improvement over the models with an LCD display. The BOM reduction and reduction in board complexity results in a product with price point with almost mass appeal.

I think it is a good design.

I have heard that it's video combining can lower the video quality?

I see it was never supposed to directly replace your floppy drive (unlike my suggestion). It allows you to keep your internal FDD (on B: ?) which I can see would be advantageous.

The videos show that it is slightly slow processing the disk images, I guess this is a limitation of the MCU they are using. Perhaps it can use pre-processed images for a speed increase?