JimDrew

I would prefer the Plaza myself.

There is still ample time to book a location and make arrangements for an event. I would prefer to use the Plaza, just because of the convenience of the restaurants and activities. This makes it a bit more family oriented compared to one of the Station Casinos.

By the way, as Joshua pointed out, offering table availability ahead of time typically reduces the overall cost to participants by not having to come a day early just to ensure that they can get a table. This also provides the organizer with an idea of a head count of attendees. I also know that it really reduces the stress of people coming and worrying about not getting any table space - which was a serious problem in all CommVEx events I have attended in the last 5 years, except last year with the giant room.

dragos, I am guessing that your room was probably affordable and you didn't have to pay $2000 for the room for a weekend, like we do in Las Vegas. Something has to help cover that cost. For CommVEx it has been sponsors, admission fee of $25 per person to attend, and raffle prizes that were donated and auctioned off. If you don't attract new people, you will never maintain (or grow) the event. This is why I have always thought admission should be free. CommVEx requires a $25 entry fee just to walk around and look what's there, and that's absurd.

Actually, I stated $25 per table - with most people I chatted with wanting at least 2 tables. Also, I don't mind organizing the event, but I would really appreciate help from the 5C's for handling publicity, setup, logistics, etc. We can talk about that at the meeting on the 21st. Let's face it, most people coming are not from Las Vegas, so you are already spending hundreds of dollars just to attend the event. Whether the event is $25 for admission or $25 for a table, the cost is the same. However, admission being free is a HUGE benefit because you can now open the event to the public, and there are many avenues in Las Vegas for free publicity to attract the general public. Why would we want the general public there? That's the only way to grow the size of the event! So, charging for table space at the same rate as CommVEx's "admission" cost yields the same cost for participants that want to setup a table and brings in more people to check out the event - which will want to attend in the future, maybe even the same day - who knows!? I kicked in $600 last year, but I didn't use 24 tables. I used 4 tables, and there was plenty of space for everyone. I also paid admission for a couple of individuals just so that they would actually come and check out the event. This event is not a money making venture for anyone. If the event breaks even, that is great, but you certainly are going to shrink the event and create animosity if you are unwilling to listen to what the people want. I have been attending trade shows since the first World of Commodore show in the early 80's, all the way up until now at NAB, CES, Sema, etc. The organizers have rules, but they certainly go out of their way to listen to vendors and spectators alike to make improvements, and that is why these successful shows are still around.

I forgot about the signage and poster restriction! John made *really* nice Commodore related signs with lights for the event last year.

Well, I tried making 4 different posts on www.commodore.ca to open a discussion thread, but those were deleted and now I have been banned. So, let's try here.... The reality is that there are a rather large group of people who have attended and/or sponsored CommVEx in the past that are not happy with the arrangements that have been made. While we all realize that the event is run by Robert and the Fresno club, there is a deliberate push to keep anyone from discussing the fact that changes need to be made in order for the event to continue to succeed. I have been a big sponsor of this event (I have donated a few thousand dollars in cash and merchandise over the last 4 years). It was a fight to grow the event and use a larger room (which we did last year). It was stated on the last day of CommVEx2016 that there would be no change for 2017. The same location and room would be used (which is still available). That changed to a completely different location, and with a room where there is no Friday room access (or setup at all), you have to setup and tear down each day with limited hours, and no night time room usage at all. There are many attendees and vendors who bring a large number of systems, software, etc. that requires a long setup period (several hours in some cases). That will not be possible with the proposed venue. The real fun of CommVEx were the night time activities. It is my hope that Robert will see this thread (and others just like it that are starting) and realize that the majority of attendees have openly stated that they will not be attending under these circumstances, and opt to make changes to return the event to what it was last year. As it stands now I won't be attending CommVEx as it is, along with a slew of others. If there is a real interest (which I believe now there is) in making a new event that everyone can attend, I would be happy to discuss this with the Las Vegas club and set this up. Banning me from www.commodore.ca is not only childish, it does nothing but make it clear that you are deliberately trying to prevent anyone from voicing their opinion. Jim Drew - CBMSTUFF.COM

If you write a bitcell that is 40ms long with the SuperCard Pro hardware, it generates a 40ms NFA on the surface of the disk. The board itself handles anything necessary to generate the exact bitcell times being sent to it. You don't need to alter any of the bitcell times to make this happen. SuperCard Pro does not require a computer to function. You could use dual drives and Sinclair ZX-81 to control it. I have a micro-controller setup that I have been experimenting with to build a copy station that has dual SuperCard Pro boards, each with dual drives (one set 5.25" and the other set of 3.5"). The only way to be able to duplicate 100% of the flux data exactly is have the hardware control the bitcell clocking that is necessary.

Nope.. no conversion in software is needed. Turrican, and bunch of other titles for the ST and Amiga use this protection, which is re-produced correctly. A strongbit (NFA) bitcell duration could last the entire revolution. I have seen a few protections for the Amiga (like on Nuclear War) that has multiple NFA's last 40ms-50ms, with valid data between. I think the total number of bitcells was around 250. With SCP you just write out the number of bitcells you want, which it turn clocks out the flux correctly. If a bitcell is 40ms, you write it back out as 40ms long. That's it. You should be able to go all the way down to below 1us pulses with a 5.25" drive. Maybe that is not the case for 48 TPI drives. I don't use those very often as I find the 96 TPI drives are far superior for reading/writing flux.

For information on how flux transitions are stored, please see the end of the .scp image file description: http://www.cbmstuff.com/downloads/scp/scp_image_specs.txt ALL flux transitions are valid - even those that people call weakbits or strongbits. The duration of a weakbit zone is always constant. The exact clock shift is random (due to the data separator clock and drive speed). In reality the magnetic flux on the surface of a disk in a weakbit zone is not actually changing. That's a bit of a myth. The start of the clocking changes each time it is read, which makes it appear to be random.

SCP creates weakbits correctly (actual weakbits, not stable transitions) - this is why it copies weakbit protected games - and only needs using a single revolution to do it. Don't believe? Try it. I have slew of weakbit protected games for the C64, Amiga and Atari ST. Strongbits and weakbits are both duplicated correctly.

If you are using a .scp image, I would recommend writing image without attempting to skip over anything. Weakbits will come out exactly like the original was read. That's how I designed it.

Just saw this... It's funny how misinformed people are. The e586dx emulation didn't require any "major" upgrade... when you purchased the e586dx module it came with a new custom logic chip that unlocked two of the chips on the board that were used by the PC emulation (but not used by the Mac emulation) - the chips were specifically for the PC emulation. It was our "copy protection", but the hardware was needed for the emulation. We did provide a free Atari 400/800 emulation (Wacke - yes, that was us) along with a free Apple II emulator. EMPLANT certainly lived up the hype and we sold tens of thousands of them, mostly all due to the Mac emulation which was replacing high-end Mac setups in places like Hollywood post-production houses because you could run circles around a real Mac with Vivid Studios software/hardware using EMPLANT. We even have a movie credit with EMPLANT and my name.. the movie was Cybertracker... check out the credits at the end of the movie. I had the very first full color Mac emulation in existence - out about a year before AMAX IV, and 2 years before Shapeshifter was created by ripping off code from both EMPLANT and AMAX IV. The e586DX PC emulation was ok.. it did work, but it was slow unless you had an Amiga with fast RAM on the CPU board, and then it was great. After UU went out of business in late 1996 (due to the death of Commodore), I created FUSION and PCx, all new Mac and PC emulators that could use the EMPLANT hardware for enhanced compatibility, but didn't actually require the board to work. So.... that is the correct information.

You can do it from the pull-down menu. Drive Settings-->Index Sensor---> (READ and WRITE have their own individual settings for REQUIRED and IGNORE).

In Window's Device Manager, go to "Universal Serial Bus Controllers" and locate the entry called "USB Serial Converter". Right-click that entry and select Properties. Under the advanced tab select "Load VCP". That instructs Windows to load a virtual com port (a COMx port). If that is not selected, you will not have a COM port setup for the SuperCard PRO board! Click OK and exit the Device Manager. You will need to remove and re-insert the USB connection to the SuperCard PRO board in order for Windows to force the loading of the VCP. I use the .dll to access the board with the SCP software, not the COM port. It's faster and there are specific buffer commands and such that I use to improve the transfer speed that are not available as a COM port only interface.

phaeron, I just grabbed your latest version and read the manual. I guess you didn't know that the SuperCard PRO hardware has always supported reading the back side of disk just by flipping it over - even if there is just a single index hole. You just need to turn off the index flag during a read or write. The drive will read/write data just fine. A few drives need a jumper change, but just about all of them work without doing anything. This is why I have never worried about doing any type of "flippy" support. If data is stored on the disk as a true double-sided disk, it will be backwards when you read it. That's easy enough to fix by reversing the flux stream before analyzing it. Prior to writing, you would have to reverse the flux stream as well. An easy way to look for the SuperCard PRO hardware on a COM port is to just send the command to get the hardware info to every COM port and look for a response.

Um... SuperCard Pro has always supported double-sided disks without having two index holes. Just flip the disk over and turn off the index sensor requirement. A8RawConv should be able to do this automatically. The SuperCard Pro hardware will read the backside of the disk without a reference to the index mark (which isn't used on 8 bit Atari disks anyways). Just read 2 revs and parse the data.

Many of the 1.44MB drives are also 360RPMs, but use 300RPMs in 720K mode. Most 5.25" 1.2MB drives can switch between 300RPMs and 360RPMs. Some do it through the density selection, and others have a dedicated jumper you can set.

The difference between 288 and 360 RPMs is 20%, which is well outside of the normal range of a decoder. My decoder works +/-49% of the bitcell width. However, the center position must be correct. I am not sure what it is set to for Atari disks - it could be 2us which is default for 1.44MB disks. I need to check that. This of course only applies to the analyzer/editor. The copier is just a flux dump/restore tool, so drive speed (and even contents) does not matter.

It's actually a huge issue. If you don't take into account the drive speed when decoding the data, it definitely will not decode correctly. A 4us pulse at 300RPMs is nowhere near 4us at 288RPMs. My decode for GCR and MFM looks at the drive speed and adjusts the decoder accordingly. I do not do that for Atari 400/800 disks (or images) that are being viewed in the analyzer, which is likely why the decoded data looks funny. Most people are using 360RPM drives for reading/writing disks with SuperCard Pro. So, going from 288RPMs to 360RPMs is a big jump!

Interesting read. So, it appears emulating a 810 or 1050 would be a very easy thing to do compared to a 1541 or other CBM drive where you can access the CPU directly. I never designed SuperCard Pro to be anything more than a means to dump flux data, but it has turned into quite a bit more than that. Several people have made utilities that access the SCP hardware directly and/or use the .scp disk image format. The HxC floppy drive emulator software (free download) will convert to/from .scp image file format to/from numerous (dozens) of different disk types, but Atari 400/800 format is not supported. :\ Well... one thing that just dawned on me is that Atari disks spin at 288 RPMs. I need to adjust the flux conversion times accordingly for Atari 400/800 disks. Maybe my FM decoder works, but the bitcell zones are wrong.

I can read and write "weakbits" (that will change every revolution when read by a native disk drive) by imaging just a single revolution using the SuperCard Pro hardware, and some software magic. So, multiple revolutions are not required to duplicate the flux exactly. Captured patterns are not "unstable", they are perfectly stable and predictable - even though they appear to change. The biggest complaint I get about SuperCard Pro is the image size and how long it takes to image a disk. This is one reason why I have the ability to set a "preservation mode" or not. The data is virtually the same, but the non-preservation data is altered slightly to produce image files that will compress substantially better than an unaltered preservation image. The Amiga emulators can actually load and use a .scp image file that is compressed with .zip, .7z, etc. 7-zip (.7z) is hands down the best compressor you can use for flux image files. The non-preservation files can be compressed to just less that 10% of their original size. SuperCard Pro is a flux level copier, with some analyzing and conversion for Amiga and C64 disks. I don't know anything really about Atari disks other than they are FM. My flux->FM decoding is not correct in the analyzer I have spent my life working on GCR and MFM formats only, so FM is something I have never had to work with before. I need to fix the flux->FM decoder, at which point I could make a routine that did error checking on the data for FM based disks. I did look at the Atari 810 and 1050 schematics and I can see how the 6532 does make a fake index pulse. Based on some info, I guess you just send commands to the drive and it responds. Thanks for that info. I may peek at your source code for your program to see how you convert my flux data to FM (unless you convert flux to raw sector data, which won't do me any good). I am not a C programmer, but I will try to figure it out.

You can always dump 2 revs using SPLICE mode and use that image for writing with SuperCard Pro or for converting to ATR/ATX format.

OK, so where do I find out more info about the Atari drives and how they interact with an Atari computer? Can the Atari ever see the CPU in the disk drive or is it limited to some type of serial communications? The reason I ask is that I have a product that I am going to release for the C64 community called uDrive (micro-drive). It is a cycle exact 6502/dual 6522/data separator emulation of a 1541 drive. I will be adding 1571 and 1581 disk drive support as well. I can emulate the 6507 (which is the cousin to the 6502), and all of the support hardware that I see in the 1050's schematic. But if copy protection couldn't poke around at the CPU or memory, then some simple code is all that would be necessary to use ATR/ATX/SCP image files with it plugged into an Atari computer.

In working with C64, Amiga, Atari ST, PC, TRS-80, and a few other formats I have never had to use more than 2 revolutions. The only way data can change from revolution to revolution is if the disk or head is dirty. The flux data itself (even what is considered by many as "weak bits") won't actually change on its own. Granted, if the disk or head is dirty you can use multiple passes to extract good data when found. Everyone should be cleaning their heads every time they start imaging disks. I clean the heads frequently, sometimes between every disk image - depending on the quality of media I am imaging. Thanks for the info on the Atari disks. What I read on the internet appears to be in error, stating that the index sensor is connected and used during formats. I guess I will have to connect my 800XL and 1050 drive and figure out how to format a blank disk and then look at it. I looked at the Floyd of the Jungle image, and you can easily see it is not index aligned by looking at the flux display in SCP's analyzer.